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.

mike.lifeguard+bugs wrote:

(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)?

PhiLiP.NPC wrote:

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.

I am not sure is this something that was solved with Translate being added to Commons, or it is a ticket about some frontend solution?