Purodha Blissenbach <> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |VERIFIED

--- Comment #3 from Purodha Blissenbach <> 
2011-02-24 15:23:54 UTC ---
(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:
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.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

Wikibugs-l mailing list

Reply via email to