Last modified: 2014-02-12 23:39:58 UTC
Currently in Wikimedia Commons you cannot localise a template like {{Information}} as you would need to embedd another translated template with another name. Currently some people are using very fragile Javascript hacks to selectively display only certain languages of a template containing let us say 40 translations. For example here: http://meta.wikimedia.org/wiki/Meta:Language_select http://meta.wikimedia.org/wiki/Template:Stub I came accross and did rewrite a MediaWiki extension that would directly enable selective display of multilingual text in MediaWiki without needing some often not working JS hacks. You can find it at http://www.mediawiki.org/wiki/Extension:Multilang and can directly download it at http://download.pakanto.org/software/ It is using the following syntax (of course not restricted to german or english): <multilang> @de|"Das ist ein deutscher Text." @en|"This is an English text." </multilang> On a wiki that has this extension enabled you will see depending from your user language setting (from Special:Preferences) either only the message in your language or if this is not existing the default system language. If your prefered language and the fallback language is not among the provided alternatives the extension shows the first text alternative as default. You can see the template in action here: http://pakanto.org/wiki/Pakanto:Mediawiki_help http://pakanto.org/wiki/Template:Category_scheme (see source code of template) As this is my first program in PHP I am aware that I did probably make some foolish errors but I am very much interested in improving this (if necessary) as this is a quite important feature that would help multilingual wikis like Wikimedia Commons and Meta a lot. And of course my extension "just works for me (TM)".
I'm not really happy with that extension; the syntax is a little weird to me. Rob Church also has a similar experimental extension in SVN with another syntax, using two separate tags in sequence, which I also think is a bit weird. :) What might make the most sense is to use something like the {{#switch}} parser function, which should... in theory... be similar to existing usages and handle nesting in a relatively sensible manner. There are some general issues; maintaining proper link table state would mean parsing all language versions and storing all their links (as {{#switch}} currently does -- which is however inefficient), and it's probably not very discoverable or legible for editing (again, as with {{#switch}}!). In general I would strongly recommend against actually using this kind of system in body text; separate pages will be *much* more easily maintained with a lot less trickery. Even I find it impossible to edit these template-within-a-template-within-a-template-called-by-a-template hackathons that people write, and this looks like it would just continue in that vein.
Thinking about it, a parser function seems to make more sense for this than a custom tag. I would also recommend to use something like that only for templates (like license tags, etc) - not sure about image description pages. As for "body text" - well, there isn't much text on commons... But let me shamelessly point you to http://www.mediawiki.org/wiki/Extension:Polyglot - it doesn't solve quite the same problem, but might be interresting to look at in this context: it implements "magic" redirects to language-code subpages. I.e. for people with a german interface, visiting Foo would take them to Foo/de, if it exists.
Why not just make a magic word like {{USERLANGUAGE}} which translates into the language code the user has selected in their [[special:preferences]], or if the url has &uselang=foo that language. Then in the template you could just call stuff as {{foo template/{{USERLANGUAGE}}}} which would be translated into {{foo template/en}} or {{foo template/zh}}, etc depending on user language preferences. Although that has a little bit of "template-within-a-template-within-a-template-called-by-a-template" as you call it, its nothing compared to some of the templates I've see on wikipedia.
I agree that having a {{USERLANGUAGE}} (or perhaps better {{ACTLANG}} for "active language") variable would be very useful. It should check in order: 1. uselang URL parameter if specified. 2. User's language preference if logged in. 3. Language of wiki and return an ISO 2-character language code. I can file a separate bug for this if desired.
(In reply to comment #4) > I agree that having a {{USERLANGUAGE}} (or perhaps better {{ACTLANG}} for > "active language") variable would be very useful. It should check in order: I think we have that now. As such do we still need this extension (esp. given it's been deemed not really suitable)?
How about using LanguageConverter? It wouldn't break any link tables because it works after main-parser. We can add a new language named "multi-language" or "neutral-language" for this, and use all of other languages as its variants. Its syntax were listed as below: -{ de:Das ist ein deutscher Text.; en:This is an English text.; zh:这是一段中文。; }- Do not need to worry about the markups ":" and ";". -{en:<span style="font-size:smaller;">Text</span>; zh:<span style="font-size:smaller;">文字</span>;}- would also be parsed currently now.
On Commons we now have {{int:Lang}} which powers [1], {{LangSwitch}} for texts [2] and {{autotranslate}} [3] for templates such as {{Apache}}[4]. I don't think we need an extension of some kind, especially since the above two have been broadly used and commonly accepted. Closing as WONTFIX. [1]: http://commons.wikimedia.org/wiki/Special:PrefixIndex/MediaWIki:Lang [2] http://commons.wikimedia.org/wiki/Template:LangSwitch [3] http://commons.wikimedia.org/wiki/Template:Autotranslate [4] http://commons.wikimedia.org/w/index.php?title=Template:Apache&oldid=46735231
(In reply to comment #7) > On Commons we now have {{int:Lang}} which powers [1], {{LangSwitch}} for texts > [2] and {{autotranslate}} [3] for templates such as {{Apache}}[4]. > > I don't think we need an extension of some kind, especially since the above two > have been broadly used and commonly accepted. > > Closing as WONTFIX. > > > [1]: http://commons.wikimedia.org/wiki/Special:PrefixIndex/MediaWIki:Lang > [2] http://commons.wikimedia.org/wiki/Template:LangSwitch > [3] http://commons.wikimedia.org/wiki/Template:Autotranslate > [4] > http://commons.wikimedia.org/w/index.php?title=Template:Apache&oldid=46735231 Re-opening this. It's my understanding that {{int:foo}} is a bad hack and I haven't seen any evidence that this is the best that MediaWiki can do or that this type of hackery should be encouraged or accepted as adequate.
If we do support that hack (my understanding is many of the caching issues were worked out - bug 14404), we should at least make a half decent way of invoking it {{USERLANGCODE}} (bug 2085 - the arguments against it aren't convincing if we support the {{int:blah}} hack. Its syntax is at least better than what is being suggested here) or whatever. {{int:lang_name}}, with requiring the user to populate the mediawiki:lang_name message is pretty stupid imho.
Although this hack isn't the best way (probably), It works, and works quite well. I don't think we need to spend time on such issues.
(In reply to comment #10) > Although this hack isn't the best way (probably), It works, and works quite > well. I don't think we need to spend time on such issues. Yes it does, for commons - but that's because they invested a lot of time making stuff in mediawiki namespace. For third party re-users it would be unreasonable to require them to do the same. Fact of the matter is {{int:...}} is here to stay, we (the devs) should embrace that its here, instead of ignoring it and pretending it doesn't exist.
