Last modified: 2014-02-12 23:39:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8287 - Enable multilingual extension in Commons
Enable multilingual extension in Commons
Status: REOPENED
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
unspecified
All All
: Low enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.mediawiki.org/wiki/Extensi...
: i18n
Depends on:
Blocks: commons
  Show dependency treegraph
 
Reported: 2006-12-16 23:14 UTC by Daniel Arnold
Modified: 2014-02-12 23:39 UTC (History)
17 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Daniel Arnold 2006-12-16 23:14:02 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)".
Comment 1 Brion Vibber 2007-04-16 21:00:42 UTC
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.
Comment 2 Daniel Kinzler 2007-04-16 21:06:31 UTC
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. 
Comment 3 Bawolff (Brian Wolff) 2007-04-17 00:14:22 UTC
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.
Comment 4 Matthew Flaschen 2008-04-20 22:46:39 UTC
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.
Comment 5 Mike.lifeguard 2009-04-01 19:19:01 UTC
(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)?
Comment 6 Philip Tzou 2009-07-24 04:35:03 UTC
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.
Comment 7 Krinkle 2011-01-31 15:16:56 UTC
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
Comment 8 MZMcBride 2011-02-01 03:16:20 UTC
(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.
Comment 9 Bawolff (Brian Wolff) 2011-02-01 04:43:08 UTC
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.
Comment 10 matanya 2012-07-23 07:11:33 UTC
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.
Comment 11 Bawolff (Brian Wolff) 2012-07-23 12:01:59 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links