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