Hi folks,
I know the summary line sounds quite lurid but this is really true and thatfor I'd like to have your attention and feedback on that matter.
You can find the following analysis of the problem as well at: http://bugzilla.wikimedia.org/show_bug.cgi?id=8188
Some time ago the I18n system of MediaWiki worked in multilanguage wikis like Wikimedia Commons the following way: * Look if there is a localised English message at the corresponding MediaWiki namespace page (directly in SQL database, not transcluded from I18n-file) regardless of the user language setting. * If the english message string is existing in the MediaWiki namespace don't use the transcluded I18n-file for that message in any language but only the corresponding /<ISO-CODE> sub page if it is directly existing. * If that page is not existing fall back to the English message * If neither the english message nor the translated message exists in the MediaWiki namespace use the transcluded string from the I18n file.
Since some months MediaWiki works the following way: * If the specific localised message is not existing in MediaWiki namespace take the transcluded message from the I18n-file.
This is one of the worst UI changes we just realised by random in Commons, seriously. We did heavily rely on the old behavior. If a message wasn't existing in the database, the user got the english one. Fine. The changes on important UI messages were easy to follow and were an acceptable amount of work. We didn't need to fear that people did get any totally useless UI messages if they did choose a less common language none of us admins was able to speak.
Until we realised the change that http://commons.wikimedia.org/wiki/Special:Upload did show just useless info and nothing what is absolutely crucial to remind during upload if you did have a less common language setting it took several months (the corresponding default message MediaWiki:Uploadtext/<ISO-code> from I18n-files is totally useless in Commons). Within that period many people did upload a lot of copyvios simply because they were not able knowing it better.
The result of that severe bug was this huge overwrite-quick-and-dirty-work-around for this single upload message only: http://commons.wikimedia.org/w/index.php?offset=&limit=50&target=Arn... (all messages with the "in order to supress a inadequate default mediawiki message" change comment).
There are much more important MediaWiki messages existing that would need such a time consuming and painfull hack ASAP.
So please look at the bugzilla report for further information and on ideas on how to solve that bug.
As well do you know which software change did cause this to happen?
Cheers, Arnomane
On 08/12/06, Daniel Arnold arnomane@gmx.de wrote:
As well do you know which software change did cause this to happen?
The only major thing I can think of that happened fairly recently is that Tim gutted and rewrote a lot of the message storage and handling mechanism.
I wouldn't, however, expect that he'd fail to test the new version under Commons-like conditions, and I haven't attempted to confirm that's the case here.
Sometimes, the MediaWiki software will refer to wfMsgForContent() instead of bog standard wfMsg(). When that happens, the function is supposed to return a message that is in the site content, or default language, regardless of the current user's preference, and it's used for data which is, e.g. licencing or important information, or that which is about to be saved into the database.
On Commons, we have an override mechanism of sorts enabled, which allows wfMsgForContent() to act the same as wfMsg() for some messages - and honour the users' language preferences. It *sounds* like this might now have become fucked up.
Your best bet would be to ask Brion Vibber or Tim Starling directly, since I'm not aware of the full details of this "override" thing, and I'm not in a position to check if it's been disabled.
Rob Church
mediawiki-i18n@lists.wikimedia.org