Per Brions request I split the isues into single pieces (although I wanted to avoid having different parallel threads on related issues):
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).
Now maintenance/update.php was changed that way that it doesn't copy UI trings anylonger into the wiki and even removes the old automatically added entries. This is in principle a good thing as this allows for some other fixes (for example in mutilingual wikis) and reduces problems with hidden message strings.
However one important thing was forgotten: The special treatment of whitelisted interface links. Now they point into the nowhere by default after running maintenance/update.php (since the link definitions from the localised message string files get used now).
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)
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).
Arnomane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Arnold wrote:
Per Brions request I split the isues into single pieces (although I wanted to avoid having different parallel threads on related issues):
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.
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""?
Now maintenance/update.php was changed that way that it doesn't copy UI trings anylonger into the wiki and even removes the old automatically added entries. This is in principle a good thing as this allows for some other fixes (for example in mutilingual wikis) and reduces problems with hidden message strings.
Right.
However one important thing was forgotten: The special treatment of whitelisted interface links. Now they point into the nowhere by default after running maintenance/update.php (since the link definitions from the localised message string files get used now).
The localized message string files and default-initialized localized message pages are identical. If there's a difference in behavior, we'll need it described.
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?
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.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
On Thursday 01 February 2007 00:20:31 Brion Vibber wrote:
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.
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:%EC%82%AC%EC%9A%A9%EC%9E%90_%EB%AA...
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
wikitech-l@lists.wikimedia.org