Last modified: 2005-06-24 21:06:56 UTC
Allow user to set the language of the interface in his preferences. This would be especially useful for Meta-Wiki and would help non-english speaking people to feel more comfortable there.
[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.
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.
202 is not blocked by this enhancement.
