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.