Last modified: 2011-07-11 12:27:06 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 9465 - Parser function to return the name of a language, given a language code, in a specified language
Parser function to return the name of a language, given a language code, in a...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 18878
  Show dependency treegraph
 
Reported: 2007-04-01 00:21 UTC by Rob Church
Modified: 2011-07-11 12:27 UTC (History)
4 users (show)

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


Attachments

Description Rob Church 2007-04-01 00:21:40 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.
Comment 1 David Augusto Villa 2007-04-01 15:47:55 UTC
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.
Comment 2 Rob Church 2007-04-01 15:53:40 UTC
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.
Comment 3 Hendrik Maryns 2007-04-06 16:42:20 UTC
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.
Comment 4 Niklas Laxström 2010-07-15 14:20:40 UTC
Doable with CLDR and I18nTags extension.
Comment 5 Ryan Kaldari 2011-04-18 18:45:05 UTC
Niklas: Can you explain your comment about CLDR and I18nTags extension? This would be very useful on Commons as well, if it is possible.
Comment 6 Niklas Laxström 2011-04-18 18:51:47 UTC
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.
Comment 7 Ryan Kaldari 2011-04-18 20:01:57 UTC
Reopening per Comment 6.

Personally, I would rather see this added to {{#language}} rather than having 2 separate magic words with very similar functions.
Comment 8 Ryan Kaldari 2011-04-18 21:45:23 UTC
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
Comment 9 Ryan Kaldari 2011-04-18 22:02:10 UTC
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).
Comment 10 Ryan Kaldari 2011-04-18 23:57:44 UTC
Bug 16699 is related.
Comment 11 Niklas Laxström 2011-07-11 12:27:06 UTC
I think this is also fixed with r91875.

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


Navigation
Links