Last modified: 2012-07-25 04:19:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T35223, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33223 - make list of 'Languages that support variant conversion' dynamic
make list of 'Languages that support variant conversion' dynamic
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.20.x
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-17 19:22 UTC by db [inactive,noenotif]
Modified: 2012-07-25 04:19 UTC (History)
6 users (show)

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


Attachments

Description db [inactive,noenotif] 2011-12-17 19:22:59 UTC
The help text for param converttitles of ApiQuery contains a static list of 'Languages that support variant conversion'. Please make it dynamic, to avoid a outdated list (iu and shi are missing at the moment). Thanks.
Comment 1 Sam Reed (reedy) 2011-12-30 22:47:30 UTC
This is somewhat of a PITA to do, and will essentially require loading of all message/language files and checking

For the moment, list of variants updated in r107665
Comment 2 Daniel Friesen 2011-12-30 22:57:51 UTC
We actually have another issue related to the way variants are done.

In most of our variants we have really weird and counter-intuitive definitions.

For example, zh defines the list of variants, and zh falls back to zh-hans. zh-tw falls back to zh-hans, zh-hant. zh-cn falls back to zh-hans. And so on.

In other words. For zh hasVariants returns true. But for zh-hans, zh-hant, zh-tw, zh-cn, etc... they all return false even though they are part of the list of variants. (Is actually a separate bug in the way of something I was trying to improve)
Comment 3 db [inactive,noenotif] 2011-12-30 23:12:37 UTC
(In reply to comment #1)
> This is somewhat of a PITA to do, and will essentially require loading of all
> message/language files and checking
> For the moment, list of variants updated in r107665

You have to load the Language*.php files, not the Messages*.php, that is right and looks not possible at that place.

Having a list in the scope of the languages object (maybe Language.php or LanguageConverter.php) can be a improvment, because than a developer will see it better, while adding a new variant, than that static list in the api, which no developer looks at, when he adds the variants to a language.
Comment 4 Umherirrender 2012-07-19 18:51:45 UTC
Gerrit change #16054
Comment 5 Umherirrender 2012-07-25 04:19:43 UTC
successfully merged

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


Navigation
Links