Page MenuHomePhabricator

Parser function to return the name of a language, given a language code, in a specified language
Closed, ResolvedPublic

Description

Author: robchur

Description:
A user was discussing some template in MediaWiki-General, 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.


Version: unspecified
Severity: enhancement

Details

Reference
bz9465

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:37 PM
bzimport set Reference to bz9465.
bzimport added a subscriber: Unknown Object (MLST).

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)
  1. Change {{#languagename}} so that it accepts a parameter that overrides the $wgLang->getCode() default
  1. 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).

I think this is also fixed with r91875.