With the current design it is not possible to know what language we actually got.

mdale wrote:

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