villadavida wrote:

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.

robchur wrote:

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.

hendrik.maryns wrote:

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.