[If you reassign a bug, please don't forget to CC wikibugs-l so notifications go out.]

Ok brion :o)

Experimental code commited in cvs HEAD allowing a user to set it's own language.

The code build the request language object and disable $wgUseDatabaseMessages.

Known issues:

• Language code isn't checked, one can set its language to 'I^@222'.
• Probably trouble when site and language use different encodings.

TODO:
Probably need to only allow languages that use the same encoding as the site.

Bug example:
On an english, iso-8859-1 encoded wiki if a user set its preference to french
he will get page output as utf-8 and his input will probably be encoded as
utf-8 !

An example for the above case:
http://wiki.twenkill.net/wiki.phtml?title=Accueil&diff=0&oldid=3308

Ip use the default site configuration : fr / utf-8
Hashar prefer english : en / iso-8859-1

ip enter some code wich get encoded as utf-8, then hashar edit the article, the
utf-8 chars
are understood correctly, and the same string is encoded as iso-8859-1.

1.4 CVS is currently badly broken, spouting null language codes and the wrong character set data. I'm going to try fixing it up...

As a temporary fix, I've added $wgUserLanguages array setting. If empty, language selection is disabled (but the UI for it in prefs isn't.
However that still needs work -- it should be a <select>, not a text input). To enable selection, list the allowed language codes in that array.
Any input not in that array will be ignored.

The current experimental language selection needs a lot of work: it doesn't distinguish between the UI language and the data processing
language, so links, namespaces, index updates, variable substitutions, etc will be done using the user selected language. This leads to
inconsistent behavior, broken links and database corruption.

Additionally en will need to be special-cased or we should move LanguageEn.php to UTF-8 to make things more consistent.

Enhancing a bit, in Setup.php I implemented a ugly hack. It now change
the site $wgAllMessages by the user language $wgAllMessages. Then rebuild
the language object.

Fix troubles with namespaces names.

Better, but this still replaces the main page link, community page link, help link, 'about' link, linktrail, etc. The navigation links should remain
if what we're trying to do is present the user interface in a different language.

Linktrail is a parser key and must not change if we want to keep a user-independent parser cache, same with any messages imported into
page text. (Really linktrail shouldn't be in the messages anyway.)

TODO: a dropdown box of available languages.

As pointed by zhengzhu on irc:
Use ./language/Names.php and code from ./config/index.php

zhengzhu coded the drop down box.

We probably have to split some messages in the allmessages array. Some messages
are related to the site (ex: name of the main page) where as other can be safely
changed.

zhengzhu wrote:

I wrote some code to test out some ideas I overhead at IRC. It is running at
http://s87257573.onlinehome.us/wiki/. The content of the site is imported from
zh.wikipedia.org. Here is how I did it: Create two language objects, one for the
content and one for the UI. Then there are two versions of wfMsg(), one gets the
message like before (through cache, db, etc) and is responsible for the content.
The other gets the message from the language files, and is responsible for the
UI. Then I trie to figure out which one should be used at where in the code.
This way we don't have to worry which message should be content message and
which should be UI message. (Sometimes it can be both.) Please test it and see
what if anything got messed up.

guanaco wrote:

202 is not blocked by this enhancement.