On Thursday 01 February 2007 00:20:31 Brion Vibber wrote:
1)
Usually UI interface links (such as "MediaWiki:Mainpage" that defines the
URL of the main page) are not localisable by default (pages
like "MediaWiki:Mainpag/de" get ignored). However you can whitelist their
i18n with "$wgForceUIMsgAsContentMsg = array();" individually in
LocalSettings.php.
2)
In the past maintenance/update.php did copy every UI message from the
default language UI message file into the wiki database.
On whitelisted UI interface
links it even did copy the default language link target into the language
sub pages in every language if there wasn't one created by hand before
(for example the content of MediaWiki:Mainpage was copied into
MediaWiki:Mainpage/de if it was empty). So if there was the link target
existing in the default language it was not possible to link people in
other languages into non-existant "localised" pages after running
maintenance/update.php (side note: this specific behaviour of
maintenance/update.php can't have been an accidential not intended side
effect).
... What? I don't understand.
"Link people in other languages into non-existant "localised pages""?
A "non-existant localised page" is a page that does not exist in that language
but people using that language get linked to by the interface.
One example. Click on this link the third link in the "navigation" (ok it is
written in korean ;-) on the left side
http://commons.wikimedia.org/wiki/Main_Page?uselang=ko
It will link you to:
http://commons.wikimedia.org/wiki/Commons:사용자_모임
This is beeing caused by the korean i18n-file embedded into:
http://commons.wikimedia.org/wiki/MediaWiki:Portal-url/ko
As you can see in:
http://commons.wikimedia.org/wiki/Special:Undelete/MediaWiki:Portal-url/ko
maintenance/update.php did overwrite this in the past with the default
language string "Project:Community Portal" and now did delete this.
How to solve
that (I don't want the old copy behaviour back as this is a
hakish solution)?
Change for link target strings (all that now need whitelisting) the
interface string resolution order from:
Mediawiki:$Message/$language-code
->$language-code-UI-String-File-$Message [further steps left out]
to
Mediawiki:$Message/$language-code -> Mediawiki:$Message (default
language) -> UI-String-File-$Message (default language)
I'm very confused. Can you provide an example?
In the example above the problem was solved by "hiding" the message file
string with copying the default language string into the MediaWiki page for
every language (that's what I meant with the ugly solution).
Now I want the new interface string resolution order for URL strings as this
would solve the problem.
In plain words:
If MediaWiki:Portal-url/ko does not exist in the wiki itself fall back to
MediaWiki:Portal-url for that URL. If that is not existing in the wiki either
fall back to the string defining MediaWiki:Portal-url in the default language
MessageXX.php file (which would be MessageEn.php in the case of Wikimedia
Commons).
That way
people don't get linked into nowhere on whiletlisted link
targets - and of course you also could entirely remove the need for
$wgForceUIMsgAsContentMsg switch in Mediawiki (and you
would get rid of one Wikimedia server maintence issue that fills your
Bugzilla).
Don't understand.
If you apply the above URL resolution oder change you don't need to disable
i18n for URL-strings by default anymore. Several people including me did bug
you several months until someone of the server admins did apply
$wgForceUIMsgAsContentMsg to said URL-strings in Commons (and at least one is
still missing and of course if we create new ones the "bother the server
admins game" starts again). This is time you can spend on something more
important than some Wikimedia Commons people wanting some interface changes
they can't do by themselves...
Arnomane