Page MenuHomePhabricator

{{int}} template call partially uses content language rather than user language
Closed, ResolvedPublic

Description

Author: mdale

Description:
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

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

Version: unspecified
Severity: enhancement

Details

Reference
bz22453

Event Timeline

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

mdale wrote:

*** This bug has been marked as a duplicate of bug 21592 ***

mdale wrote:

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.

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.