Last modified: 2012-07-28 20:42:18 UTC
When calling an internationalizeded message with {{int:...}}, PLURAL (and with it likely GENDER, etc.) may show unexpected results. They appear to be using the wrong language routines. See page http://translatewiki.net/w/i.php?title=User:Purodha/bug_21592 for a set of examples. There, we see figures 0, which according to the messages called, should not be there. Likely, int: uses the routines for PLURAL, GENDER; etc. of the wiki language, even if a message comes from another language than the wiki language, such as with {{int:some-message/some-language|parameters...}} The solution would have to be to extract the language from the 1st parameter to int: , and use it to call the processors for PLURAL, GENDER; etc. of the correct language object.
With the current design it is not possible to know what language we actually got.
*** Bug 22453 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > With the current design it is not possible to know what language we actually > got. Indeed, the logic finding a message string returns a message string without any additional information. What was needed to treat this message string correctly are generally: A. encoding and charset (Not a problem, we luckily now have UNICODE everywhere) B. language - more preicisely: locale (language + area + script + orthography + ... ) C. directionality. All of those must be known at least to render correct html with correct character encoding and the necessary xml/html attributes: xml:lang="..." lang="..." dir="..." set correctly for each piece in the final page. The locale must be known so as to find the correct routines for message magic such as PLURAL, GENDER, or GRAMMAR, formatnum, etc., and possibly int. In a rendered page, various text from various sources comes together. Parts may come from: - the wiki language - any fallback language of the wiki language - a user language (preferences, uselang=, accept-language header) - any fallback language of the user language - the page language, if any (c.f. page MediaWiki:mainpage/zh) - any user-set fallback language ( planned, see bug 11267 ) Obviously, PLURAL, GENDER, formatnum, GRAMMAR routines etc. have to match the respective message locale each, no matter of the mix of message sources. Obviously, this in not so for the int hack, since examples: 1. Klick the {{int:go}} button. -- (should render whatever wfMsg('go') does) 2. Block this user ({{int:log}}, {{int:contribs}}) -- (use msg language) show diverging demand. Thus int needs a redesign. Leaving alone int, all other demand can be met by accompanying each message text with either: - a link to its language-object (which knows locale, directionality, and routines for GENDER, formatnum, etc. - a set of attributes, at least locale (or locale + directionality) from which the matching routines and other data can be dynamically found on demand. Alternatively, current message texts could be replaced by a structure including the above. In the future, this could be consequentially extended into a truly multilingual wiki, where all pages (or sections in pages) have languages of their own.
