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.

yes, that's doable on the technical level.

The purpose of only allowing content language to be modified through the mediawiki namespace is to ensure a somewhat consistent user interface across the different languge sites. Otherwise, if every language can be changed by anyone, then someone visiting say en.wp using fr as UI, may have rather different experience when visiting de.wp using fr as UI, because people at the two sites decided to modify fr differently.

---

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.

-- Rowan Collins BSc [IMSoP]

These are being fixed. I think I got the namespace names part right so far:) The problem with 'mainpage' is due to a new patch to SkinPHPTal.php, and has been fixed in cvs.

Please report similar issues to this thread or to bugzilla!

Also, if you write new code that need to use $wgLang, or need to call wfMsg*, please take into consideration the difference between the UI elements and the content elements. For example, if you want to make a link to the mainpage, it should look something like this, roughly speaking:

here is the <a href= wfMsgForContent('mainpage') > wfMsg('mainpage') </a>

-- zhengzhu