Last modified: 2011-02-24 12:29:20 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 T24453, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22453 - {{int}} template call partially uses content language rather than user language
{{int}} template call partially uses content language rather than user language
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-09 19:20 UTC by Michael Dale
Modified: 2011-02-24 12:29 UTC (History)
1 user (show)

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


Attachments

Description Michael Dale 2010-02-09 19:20:16 UTC
The issue comes up when you want to get a localized message from the api that includes parser logic. 

For example: http://www.mediawiki.org/w/api.php?action=parse&uselang=wa&text={{int:undelete_short|0}}&format=json

returns: <p>Rapexhî 0 candjmints</p>

wa language uses singular form for zero, so the proper transformation per uselang should be: 
<p>Rapexhî on candjmint </p>

It should certainly not be a mix of the "wa" language key with the "English" plural parser logic. 

There are two possible solutions that I see:
1) We use "uselang" language instead of wgContentLang when doing action=parse. This could add a check at the api level for uselang and override wgContentLang.
or 
2) We could have a separate api entry point for localizations with transforms ( ie extend the meta=allmessages entry point with msg arguments. Avoiding the action=parse and {{int}} hack all together.
Comment 1 Michael Dale 2010-02-09 19:33:40 UTC

*** This bug has been marked as a duplicate of bug 21592 ***
Comment 2 Michael Dale 2010-02-15 17:58:34 UTC
This was solved with solution 2, ( extending the api ) r62532

The issues with {{int}} hack have not been fixed, but at least now you can get PLURAL and other msg transforms from the api.
Comment 3 Purodha Blissenbach 2011-02-24 12:29:20 UTC
This solution works only for strings localized in the language in question.
It fails, when a message in a fallback language is returned.

See bug 21592 comment 3 and following.

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


Navigation
Links