MediaWiki talk:AjaxTranslation.js

If you don't like this feature and want to disable it, you can do so by adding the line window.disableAjaxTranslation = true; to your monobook.js, vector.js or the appropriate .js subpage for other skins.

Documentation

This script allows certain multilingual templates (most commonly license tags, like {{Cc-by-sa-3.0}}) to be translated in-line on pages. Its purpose is to improve user experience by exposing less of the ugly internal details of the {{Autotranslate}} system to users who just want to read licensing information in their preferred language and by allowing them to do so while staying on the page to which the information applies.

How does it work?

To allow a template's content to be translated in-line, its outermost enclosing element (usually a <div> or a table, typically specified in the "/layout" subtemplate) must be given the class "layouttemplate". The template must also possess the usual {{Autotranslate}} setup, including a set of language links pointing to "/xx" subtemplates, where xx stands for the ISO language code.

The script looks through the page source for elements having the "layouttemplate" class and add a click event handler to any language links found within them. This event handler uses the MediaWiki API to render the appropriate translated version of the template and to replace the original element with the translated version.

Known bugs and issues

Unfortunately, the current implementation has a number of issues and limitations, mostly caused by the fact that the existing template translation system was not originally designed with in-line translation in mind. Below is a list of some issues that template authors should be aware of.

• The "layouttemplate" class must be placed on the outermost HTML element surrounding the entire template (or at least surrounding each of the translation subpages). Any template content outside the element with the "layouttemplate" class will not be replaced with the translated content, and if the user clicks multiple language links, several copies of such content will accumulate on the page. Also, there should be only one element with the "layouttemplate" class per (translated) template. It might be possible to partially fix this so that anything outside the outermost element with the "layouttemplate" class is stripped from the translated content before replacement. This would remove the accumulation issue, but would still leave any content outside that element untranslated. (Note that it's OK to have extra content outside the element with the "layouttemplate" class on the main template, like on {{GFDL}}, just not on the translation subpages. Also, anything wrapped in <noinclude> tags is fine, since it won't be shown on the page.)

• Any parameters given to the template are lost and replaced with their default values when the template is replaced with a translated version. (This has, in effect, always been the case, but without in-line replacement users would not have expected anything else.) In particular, this makes the in-line translation system essentially unusable for container templates like {{Information}} or {{Self}}. This is a major problem, and unfortunately a hard one as well: fixing it would require some kind of new scheme for passing the raw parameter values to the script. Some of the effect of this bug can be mitigated by providing useful and non-misleading default values for parameters.
  • A still somewhat experimental mechanism for parameter passing now exists in the form of {{LayoutTemplateArgs}}. See the documentation of that template for instructions on how to apply it to a new or existing template.

• If any translated version of the template is broken in some way (e.g. missing or incorrect language links, missing "layouttemplate" class, translation missing entirely), a user who clicks the link for that language may not be able to switch back again, except by reloading the page. It might be possible to add some consistency checks on the translated content, but this issue cannot be fixed entirely in the script. The real solution is to fix the broken translations.

• If two templates using the in-line translation system are nested within one another, clicking one of the language links for the outer template will change the language of the inner template as well. (Note that this happens only if the nested template is actually inside the translated content, not for arrangements like the one used on {{GFDL}}.) In some cases this might be considered a feature.

• The use of the language links for in-line translation makes it harder to reach the actual subtemplates for editing. This should not be major issue, as the majority of users who click on those links presumably only wish to view the translations, not to edit them. Users who do wish to reach the template pages themselves may use one of the following methods:
  1. Right- or middle-click the links to open them in a new browser tab or window. The script should not interfere with this in any way.
  2. Click the "+/-" link to reach the "/lang" subtemplate, and navigate to the desired language subtemplate from there.
  3. Use the usual method for editing templates used on a page: click the "edit" tab and select the approppriate template from the "templates used on this page" list below the edit box.

Discussion

Issues

Great feature. I came across those issues though :

• No support for characters such as "é", as in {{Mérimée}} (See doc for example). Well, maybe it was dumb to use such characters in a template name, for which, as the creator, I apologise :-)
• Parameters are not passed to the selected language. See for example (among countless others) {{Palissy}}.
• Problem with a template nested in the template, as in for example {{ComInRo}}. At the language selection of the main template, the nested template (here, Attribution) is switched to English.

Hoping this could help, Jean-Fred (talk) 14:19, 27 December 2009 (UTC)

 Comment: The second problem is also the same as if you click on the language link and see the template there. It also doesn't recognize the parameters, but this solution has the advantage that one doesn't need to leave the image description page. --The Evil IP address (talk) 15:54, 27 December 2009 (UTC)

The first seems to be some kind of encoding bug. I'll try to fix it ASAP. The two other issues are unfortunately more or less unfixable in the current implementation: they'd require both major changes to the templates themselves and a full rewrite of the script. In the long term, it would be better to set up a new template translation scheme that could support those features. I've been thinking a bit about how such a scheme might work, but it seems quite tricky. (Or, rather, it seems tricky to do while retaining all the useful features of the current system, such as graceful degradation in the absence of JS and/or CSS support.) —Ilmari Karonen (talk) 18:30, 27 December 2009 (UTC)

OK, the double encoding bug should be  fixed now. —Ilmari Karonen (talk) 18:40, 27 December 2009 (UTC)

Also  partially fixed the nested template issue: the inner template now changes to the same language as the outer template (or to the closest fallback language available). If this is not desired, consider restructuring the template so that the inner template is not nested withing the autotranslated part of the outer one. —Ilmari Karonen (talk) 06:25, 31 December 2009 (UTC)

AJAX can pass parameters to the template that needs to be rendered. So the only problem is, that AJAX doesn't know what parameters where used to render the page, right? Shouldn't it be possible to add an additional tag to the template, that is hidden from view and contains the parameters? Like {{Palissy|type=classé|PM16000192}} being rendered as:

<div class="layouttemplate">
<dl class="layouttemplate_parameters">
<dt>type</dt><dd>classé</dd>
<dt>1</dt><dd>PM16000192</dd>
<dt>2</dt><dd></dd>
<dt>3</dt><dd></dd>
</dl>
<table cellspacing="8" cellpadding="0" style="width:100%; clear:both; margin:0.5em auto; border:2px solid #688C68; text-align:center; background:#D5E5D6; direction: ltr;">
// ... //
</table>
</div>

--Slomox (talk) 15:16, 2 January 2010 (UTC)

That could work, except that it needs at least a hardcoded style="display:none;speak:none;". (Our pages get shown on other projects, which won't have our site CSS.) It'd also still look pretty awful to users with no CSS support at all.

A possible alternative might be to encode the parameters in the language links themselves using the {{urlencode:}} parser function (either in a dummy query parameter or in the anchor portion), or possibly in a separate hidden link. Or, hmmm... it seems MediaWiki allows setting custom title attributes on tags, so perhaps something like <span class="layouttemplate-params" title="type=class%C3%A9&1=PM16000192&2=&3=">&nbsp;</span> might work. —Ilmari Karonen (talk) 15:50, 2 January 2010 (UTC)

Thinking out loud a bit more... one problem is where all that code should be put. For the script, the most convenient place would be inside the element with the "layouttemplate" class, which would logically mean putting it in the "/layout" subtemplates. But those subtemplates don't generally receive the raw args in the current scheme, and they're called via the "/xx" language subtemplates, so adding a new parameter to them would mean having to modify all the language subtemplates. But that would require a huge number of edits, and would be error prone besides.

In fact, the only way to do it without changing all the language subtemplates would be to put it in the main template itself. But that'd put the args outside the "layouttemplate" element, making them harder for the script to find, and would also mean that the script would have to remember them internally, since it generates the translated versions by calling the language subtemplates directly (and it must do that, otherwise it'd break for templates like {{GFDL}}). Damn. —Ilmari Karonen (talk) 16:09, 2 January 2010 (UTC)

Okay, I now have a prototype implementation of argument passing coded and enabled at Template:Palissy. It needs more documentation and testing, but it seems to work. Woohoo! —Ilmari Karonen (talk) 17:04, 2 January 2010 (UTC)

"speak:none;"? Is that really needed? Seems to me that "display:none;" should suffice.[1] Otherwise I'll have to adapt a number of ImageAnnotator templates... Lupo 13:24, 3 January 2010 (UTC)

Frankly, I'm not sure. The spec you linked to seems to imply it isn't, but doesn't seem to say so very clearly, and I don't have an aural browser to test it with. However, I've seen people use the combination "display: none; speak: none;" elsewhere, and figured it's better to be safe than sorry. —Ilmari Karonen (talk) 13:42, 3 January 2010 (UTC)

I've now activated the argument-passing for {{Attribution}}, and it seems to work fine there as well. There's also now documentation at {{LayoutTemplateArgs}} (which might've been a bad choice of name... better suggestions are welcome). It's not particularly difficult to use, just a bit tedious if you end up having to edit all the translations of a widely translated template. Using a semi-automated editing tool of some kind is recommended. —Ilmari Karonen (talk) 21:55, 5 January 2010 (UTC)

POTY voting pages

FYI, I enabled it on the voting pages where {{2009POTY/header/R1}} is used. It uses a bit different formatting from the autotranslated templates, but it worked for me. --The Evil IP address (talk) 08:58, 14 May 2010 (UTC)

Detecting and saving languages

With the success of {{Mld}} (MediaWiki:Multilingual description.js) I think it'd be a good idea to built cookie-saving and browser-detection of language in this script aswell. Based on priority: 1: Cookie, 2: wgUserLanguage (if logged in) and 3: browser-detection. This could be integrated at the begin of initAjaxTranslation(), then when going through all of them with updateLangLinks() it could check if there's a link for the detected language of choise, and if the language of choise is present and it's not equal to wgUserLanguage (because MediaWiki does that already), do it right away. I currently don't have time to do this, I might have after the holidays. In the mean time, what do you think ? –Krinkle^talk 01:25, 23 July 2010 (UTC)

Broken on Firefox?

Hi folks,

Since a few days, AjaxTranslation does not work for me anymore on Firefox 3.6.1 (logged or not) ; but it does on Opera 10.62 (both on Ubuntu 10.04).

Am I the only one? (Please tell me if you need additional info).

Jean-Fred (talk) 22:54, 28 September 2010 (UTC)

Nope, you're not alone. Is caused by this change. It causes an access to argsElements[argsElements.length], which doesn't exist if the loop above terminates normally. I don't quite understand what Krinkle was trying to do there; the original looks fine to me (modulo coding style; I have a habit of not using loop counter variables outside the loop). Lupo 08:45, 29 September 2010 (UTC)

{{World Koppen Map Legend}}

Hello, Ajax Translation does not work on that one {{World Koppen Map Legend}} . Any idea why? Jean-Fred (talk) 18:14, 20 September 2011 (UTC)

$.escapeRE → mw.RegExp.escape

{{Editprotected}} Could someone update this script to not use the deprecated $.escapeRE? Helder 00:13, 1 July 2015 (UTC)

@He7d3r: Aren't you able to do this on your own as a global-interface-editor? Just wondering – I know nothing when it comes to programming or the GIE right. INeverCry 22:31, 6 July 2015 (UTC)

They can, but whether they are allowed is written on another paper. Stupid bureaucracy. -- Rillke^(q?) 07:52, 7 July 2015 (UTC)

Yeah, I could do that, but I remember vaguely some negative reactions here on Commons when some other user with these permissions edited some js/css page, due to the fact that there are a good number of active users who can make these edits. Helder 16:23, 8 July 2015 (UTC)

 Done Awesome! Thank you! Rillke^(q?) 07:57, 7 July 2015 (UTC)

This behavior is very strange, all my scripts are now broken due the very short deprecation-warning period (due User:Magog the Ogre/cleanup.js)!!! Why? Anyway thanks for fixing. ↔ User: Perhelion (Commons: = crap?)  11:19, 7 July 2015 (UTC)

@Perhelion: you should add a dependency on the modules your scripts are using. See also phab:T105261. Helder 18:42, 10 July 2015 (UTC)

@Helder Yes I am aware of this. But all scripts break because only one script breaks (not my own). Yes, I used trimRight in another script and I thought it was already in jQuery. I write now my own functions to be not depending from variable annoying deprecation module loading. I mean the deprecation was only one week!? ↔ User: Perhelion (Commons: = crap?)  08:04, 11 July 2015 (UTC)

@Perhelion: It is possible to prevent that by using something like

mw.loader.using(['mediawiki.RegExp']).done(function(){importScript('User:Maintainer/SomeScript.js');});

until the "User:Maintainer/SomeScript.js" is fixed. This will make "mediawiki.RegExp" to be loaded before SomeScript.js. Helder 12:00, 11 July 2015 (UTC)

Thank you, indeed this seems a good way (for experienced users). Have a nice weekend. ↔ User: Perhelion (Commons: = crap?)  14:07, 11 July 2015 (UTC)

Incompatible with NavPopups

{{Editprotected}}

Navigation Popups (a rather popular gadget, in top 10 according to gadget statistics) sets link title to empty string when hovering over links, so it’s deterministically falsy in the if in line 56. The could should rely on link target instead. —Tacsipacsi (talk) 23:45, 3 July 2019 (UTC)

I’ve prepared an update at User:Tacsipacsi/AjaxTranslation.js. In addition to NavPopups incompatibility, it also fixes live preview/VisualEditor incompatibility. —Tacsipacsi (talk) 22:30, 5 July 2019 (UTC)

 Done Awesome! Thank you! -- User: Perhelion 12:17, 30 July 2019 (UTC)

@Perhelion: I’ve just noticed that the new version doesn’t work with template titles containing non-ASCII characters. Changing line 59 to

if (tmpName) tmpName = decodeURI(tmpName[2]);

seems to fix the issue. —Tacsipacsi (talk) 15:34, 14 September 2019 (UTC)

 Done Thank you! -- User: Perhelion 08:23, 16 September 2019 (UTC)

Do we still need language links under templates?

In 2009, the "AjaxTranslation.js" script was developed and enabled by default. This script works as follows: when reading a page (for example, a file description page) that includes a translated template and you click on one of the language links, the script (in the background) make a web request to the MediaWiki API to re-render that template (with the same template parameters, and in context of the same page title for magic words etc), and then dynamically replaces the template part of the current page with a translated version.

I believe this script was originally aimed at visitors without a registered account, since logged-in users can set the interface language in their preferences, which most templates on Commons (such as Template:Delete) adapt to automatically without needing a gadget like this.

In 2011, we enabled the "AnonymousI18N" gadget by default on Commons, which also provides a language selector in the sidebar for everyone else.

It was recently reported that the language links stopped working for Template:Delete (as of Jan 2021, per thread "Language links are broken"). I've repaired the script now, but this got me thinking.. is this gadget still useful? And by extent, are the language links at the bottom of each template inclusion worth keeping and presenting as prominently as we do? Krinkle (talk) 23:04, 9 January 2022 (UTC)

@Krinkle: How would removal affect non-English-speaking users who are unwilling or unable to run JavaScript? How about those who are not logged in?   — Jeff G. ツ _{please ping or talk to me} 23:20, 9 January 2022 (UTC)

Personally I am more inclined towards their inclusion as the default language of the Wikimedia Commons is English and most people around the world don't speak it, also if someone travels abroad and doesn't have an account and the language might be localised this could confuse them (I am assuming that this is how it works, if not then it's always English by default and a non-Anglophone might not know how to switch the language). I personally don't see why the links would be a bad thing to keep as most templates that use them tend to be brief and often link to relevant police and / or guideline pages. As a multilingual website I think that these links are probably more intuitively to keep.

Also, imagine if a person has a working understanding of English but needs the more technical things of how things work explained to them in another language then they are probably likely to use this website in English but would need to occasionally switch to Basque, French, Italian, or something and these handy links would allow them to switch more easily only for one page rather than change the display language for all pages. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:05, 10 January 2022 (UTC)

Another benefit of retaining the links is that someone can see at a glance which languages have or have not been translated. Some of the template translations we receive may be from bilingual people who spot that we have one but not the other of the languages they speak. From Hill To Shore (talk) 13:24, 10 January 2022 (UTC)