Last modified: 2005-06-24 21:06:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 184 - Changing language of UI in user preferences
Changing language of UI in user preferences
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Antoine "hashar" Musso (WMF)
:
Depends on:
Blocks: 202 588 1020
  Show dependency treegraph
 
Reported: 2004-08-21 16:55 UTC by elian
Modified: 2005-06-24 21:06 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description elian 2004-08-21 16:55:12 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.
Comment 1 Brion Vibber 2004-09-08 02:41:39 UTC
[If you reassign a bug, please don't forget to CC wikibugs-l so notifications go out.]
Comment 2 Antoine "hashar" Musso (WMF) 2004-09-08 03:46:31 UTC
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.
Comment 3 Antoine "hashar" Musso (WMF) 2004-09-08 03:51:59 UTC
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 !
Comment 4 Antoine "hashar" Musso (WMF) 2004-09-08 03:59:52 UTC
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.
Comment 5 Brion Vibber 2004-09-08 07:15:30 UTC
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...
Comment 6 Brion Vibber 2004-09-08 07:39:19 UTC
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.
Comment 7 Antoine "hashar" Musso (WMF) 2004-09-08 13:36:43 UTC
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.
Comment 8 Brion Vibber 2004-09-08 17:45:30 UTC
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.)

Comment 9 Antoine "hashar" Musso (WMF) 2004-09-17 11:37:48 UTC
TODO: a dropdown box of available languages.

As pointed by zhengzhu on irc:
Use ./language/Names.php and code from ./config/index.php
Comment 10 Antoine "hashar" Musso (WMF) 2004-09-17 19:04:38 UTC
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.
Comment 11 zhengzhu 2004-09-20 22:13:10 UTC
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.
Comment 12 Guanaco 2004-11-25 22:04:54 UTC
202 is not blocked by this enhancement.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links