Last modified: 2011-07-11 12:27:06 UTC
A user was discussing some template in #mediawiki, and a brief discussion started, where I suggested we provide some sort of parser function which would allow editors to obtain the name of a language given its language code, in the content, or any other specified language. Something like: {{#lang:<target>|<language to use>}} would be good. This would require setting up a decent backend to hold the translations, perhaps based on our current i18n model, or perhaps a database or some serialised storage.
Instead of using {{#lang:}} you could overload {{#language:__}} to take this other parameter, the language to use. That is, the specs would allow either {{#langage:<target>}} or {{#language:<target>|<language to use>}}. But really what would be most useful is the name of the language in the language of the project. That is, implement it so that, just like {{#language:__}}, {{#language:__|en}} is serialized on en.project.org, but the other translations are either unimplemented or less efficient.
Overloading {{#language}} might be possible, or it might not - it might require modifications to the parser function extension mechanism to allow hooks to override each other. It doesn't matter if we provide language names in the language of the project, their native language, or some other; we still have the initial set-back of setting up efficient storage and retrieval, and we still have the problem of co-ordinating the translations.
This would actually help us on en.wiktionary a lot (and probably most other wiktionaries, because then they can use the same trick, which is needed a lot): Often, words need to have their language name appended to refer to the right section on the page, e.g. [[kaka#Old Norse|kaka]]. In several templates, we want this to be automated. It is too server intense to use {{langcode}} templates for that. This extension would prove a solution.
Doable with CLDR and I18nTags extension.
Niklas: Can you explain your comment about CLDR and I18nTags extension? This would be very useful on Commons as well, if it is possible.
CLDR provides the language names (partially at least). Then it is up to a magic word to provide interface to that. I thought #languagename from i18ntags would do it but looks like I was mistaken.
Reopening per Comment 6. Personally, I would rather see this added to {{#language}} rather than having 2 separate magic words with very similar functions.
After looking deeper at {{#language}}, CLDR, and I18nTags, I think the most logical thing to do is: 1. Move {{#languagename}} from I18nTags to CLDR (since otherwise the 2 extensions are basically dependent on each other) 2. Change {{#languagename}} so that it accepts a parameter that overrides the $wgLang->getCode() default 3. Deploy CLDR extension to the Wikimedia cluster
I checked in the fix for #2 above in r86350. Just made it so that the languageName() method could deal with values other than 'native' for the 3rd parameter (while remaining backwards compatible).
Bug 16699 is related.
I think this is also fixed with r91875.
