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, 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

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz9465.
bzimport created this task.Via LegacyApr 1 2007, 12:21 AM
bzimport added a comment.Via ConduitApr 1 2007, 3:47 PM

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.

bzimport added a comment.Via ConduitApr 1 2007, 3:53 PM

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.

bzimport added a comment.Via ConduitApr 6 2007, 4:42 PM

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.

Nikerabbit added a comment.Via ConduitJul 15 2010, 2:20 PM

Doable with CLDR and I18nTags extension.

kaldari added a comment.Via ConduitApr 18 2011, 6:45 PM

Niklas: Can you explain your comment about CLDR and I18nTags extension? This would be very useful on Commons as well, if it is possible.

Nikerabbit added a comment.Via ConduitApr 18 2011, 6:51 PM

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.

kaldari added a comment.Via ConduitApr 18 2011, 8:01 PM

Reopening per Comment 6.

Personally, I would rather see this added to {{#language}} rather than having 2 separate magic words with very similar functions.

kaldari added a comment.Via ConduitApr 18 2011, 9:45 PM

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
kaldari added a comment.Via ConduitApr 18 2011, 10:02 PM

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).

kaldari added a comment.Via ConduitApr 18 2011, 11:57 PM

Bug 16699 is related.

Nikerabbit added a comment.Via ConduitJul 11 2011, 12:27 PM

I think this is also fixed with r91875.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.