The basic functionality of switching the UI language is in CVS HEAD. I see test.wp is already running it, so please take a look.
The current implementation is largely suggested by Tim Starling (at least I heard it from him...): We explicitly separate the UI language and the content language, and create two language objects: wgContLang and wgLang. wgLang is for the UI and wgContLang is for the content. The original wfMsg* functions will specifically fetch message for the UI, and wfMsgForContent() and wfMsgNoDBForContent() should be used for content.
Only messages of the content language (and supported variants, such as zh-cn and zh-tw for zh) are stored in the MediaWiki: namespace. All message keys are suffixed by the language code in the namespace. For example, 'mainpage' will be 'mainpage/en' in the en site, and 'mainpage/fr' in the fr site, etc. This is mainly for the purpose of supporting multiple variants (e.g. zh-tw and zh-cn) in the namespace.
Right now the UI language option is only accessible for registered users through the preference page. I think we should also place a selection box somewhere in the mainpage for anonymous users so they can choose the UI language as well.
On Sun, 2004-09-26 at 20:47 -0400, zhengzhu wrote:
Right now the UI language option is only accessible for registered users through the preference page. I think we should also place a selection box somewhere in the mainpage for anonymous users so they can choose the UI language as well.
Of course, it _should_ default to a content-negotiated language based on the browser preferences and the available languages on the server... right? I mean, that's just the Right Thing to do.
We have some content negotiation code in Mediawiki already. Right now I think it does MIME types, but it could be quickly adapted to doing languages, too. We should take some time to do qs ratings for the available language files.
~ESP
Evan Prodromou wrote:
On Sun, 2004-09-26 at 20:47 -0400, zhengzhu wrote:
Right now the UI language option is only accessible for registered users through the preference page. I think we should also place a selection box somewhere in the mainpage for anonymous users so they can choose the UI language as well.
Of course, it _should_ default to a content-negotiated language based on the browser preferences and the available languages on the server... right? I mean, that's just the Right Thing to do.
We have some content negotiation code in Mediawiki already. Right now I think it does MIME types, but it could be quickly adapted to doing languages, too. We should take some time to do qs ratings for the available language files.
~ESP
It would be really great if the user interface is something that can be set in user preferences in other projects than just zh: ; it would make a lot of difference in data driven projects like WikiData, WikiSpecies and with a database backend Wiktionary.
I would prefer to have this only for registered users because it will prevent people changing stuff to their local language (not a good idea in the datadriven projects). When registering, the user would be more aware of what the project does and this would prevent a lot of these errors.
Thanks, GerardM
It would be really great if the user interface is something that can be set in user preferences in other projects than just zh: ; it would make a lot of difference in data driven projects like WikiData, WikiSpecies and with a database backend Wiktionary.
It is not specific to zh. But the zh site supports multiple variants in the content, which is uniq atm.
I would prefer to have this only for registered users because it will prevent people changing stuff to their local language (not a good idea in the datadriven projects). When registering, the user would be more aware of what the project does and this would prevent a lot of these errors.
I think there is internal measurements to make sure only sysop can modify the mediawiki namespace. The UI switching itself is per user, so you and I can use different UI languages at the same site, for example.
On Sun, 26 Sep 2004 20:47:37 -0400, zhengzhu zhengzhu@gmail.com wrote:
The basic functionality of switching the UI language is in CVS HEAD. I see test.wp is already running it, so please take a look.
[...]
Only messages of the content language (and supported variants, such as zh-cn and zh-tw for zh) are stored in the MediaWiki: namespace. All message keys are suffixed by the language code in the namespace. For example, 'mainpage' will be 'mainpage/en' in the en site, and 'mainpage/fr' in the fr site, etc. This is mainly for the purpose of supporting multiple variants (e.g. zh-tw and zh-cn) in the namespace.
Isn't this going to be a bit awkward when anyone changes a MediaWiki message, and finds that they can't switch non-local speaking users away from the default? I mean, sometimes things like "Current events" get turned into something significantly different, like Meta's "Goings on".
But then, perhaps a site like Meta: or a "data-based project" could just have *all* languages as "supported variants" (is this going to be a setting somewhere?), and attempt to propogate any major changes across each of the /langcode sub-pages.
----
Ah! Bug alert: some MediaWiki messages/translations determine the target of links. Different languages default these links to different locations, so putting the TestWikipedia in German gives me a link to http://test.wikipedia.org/wiki/Hauptseite rather than http://test.wikipedia.org/wiki/Main_Page. Perhaps destinations like this need to be stored seperately in some global (language-independent) part of the MediaWiki: namespace, and referenced in the default translations for each language - : in LanguageDe.php "[[ {{MediaWiki:mainpage}} | Hauptseite ]]" : of course, for UI language == content language, "[[ {{MediaWiki:mainpage}} | {{MediaWiki:mainpage}} ]]" gives the equivalent of the current system In short, the *text* of such links can be translated, but their *target* needs to reflect the actual location on this wiki, wherever it appears.
I would have guessed this would affect namespace names as well (e.g. User:, User_talk:), but I can't find any instances of this being the case so far.
On Monday 27 September 2004 02:47, zhengzhu wrote:
Right now the UI language option is only accessible for registered users through the preference page. I think we should also place a selection box somewhere in the mainpage for anonymous users so they can choose the UI language as well.
For anon users, browser language might also be recognised.
On Mon, 27 Sep 2004 15:38:49 +0200, Nikola Smolenski smolensk@eunet.yu wrote:
On Monday 27 September 2004 02:47, zhengzhu wrote:
Right now the UI language option is only accessible for registered users through the preference page. I think we should also place a selection box somewhere in the mainpage for anonymous users so they can choose the UI language as well.
For anon users, browser language might also be recognised.
This is what the earlier references to "content negotiation" meant. Basically, a browser can be set to have a prioritised list of preferred languages, which are sent with every request to a web server; the server can then interpret this data, and return a different version of the requested document in order to match those preferences as best as possible. In MediaWiki's case, we could simply select the UI that matched the highest priority language given by the browser.
I see one disadvantage to this: caching. We're going to need some pretty clever partial caching if too many non-English-speaking anons visit en...
zhengzhu wrote:
The basic functionality of switching the UI language is in CVS HEAD. I see test.wp is already running it, so please take a look.
Hello,
I would like to thanks you for your work on this. Specially splitting the contentlang and the sitelang :o)
wikitech-l@lists.wikimedia.org