First of all, in general, there will always be a risk of breaking unusual stuff with our development model, because the testing phase depends on developers noticing stuff in their local copies. This not only is kind of shallow, it also totally ignores some options that might be very important to some wikis. Particularly relevant to this is that I assume every developer's local wiki is in their preferred language, and since they're the only user, it seems likely that they wouldn't have a different language from the default. Maybe someone runs a wiki with the content language different from their user language, but I at least don't (right now!).
A few things I'd like to comment on.
On 1/30/07, Daniel Arnold arnomane@gmx.de wrote:
The Monobook skin hardcodes first letter lower case for certain UI-messages (CSS: .portlet h5, .portlet h6). This is a totally bad idea considering languages that use upper case a lot in order to differentiate different words and meanings. German is probably the most common example for such a language. As long as you use a monolingual (German) wiki a hackish solution works; see MediaWiki:Monobook.css/de in your wiki of choice for the CSS code. As CSS files can't be (and shouldn't need to be) localisable using the sub page style the solution doesn't work in mutilingual wikis as now people of all other languages complain that their interface strings are upper case, since it seems to be "good style" starting every interface string affected by the ".portlet h5, .portlet h6"-rule with upper case and later forcing it again to lower case. So the solution is: Drop the forced lower case in Monobook and if you don't like your UI strings starting with upper case in your language of choice make these strings lower case right from the start in vanilla MediaWiki. There is no other good solution.
Perhaps. The problem is that your solution affects other skins as well. It would be possible to add classes for the content and interface languages to body, but that won't necessarily work if some of the relevant messages are inheriting from some other language. I'm not sure how to best deal with this.
Interface string problems:
- Above interface strings were already covered a bit. There is a second
problem with link targets pointing into nowhere. Vanilla Mediawiki strings contain hardcoded localised link targets. For example have a look at MediaWiki:Blockedtext (if you want to get all (?) affected messages grep for {{ns:project}}). Well again in monolingual wikis no problem. These linked pages are supposed to exist but now consider a multilingual wiki... People using $non-default-language get pointed into nowhere and as we have quite a lot languages supported in Mediawiki this means a lot of pages you'd need to create in previous or if you don't wat that touching a huge number of interface strings. So in vanilla Mediawiki please do not hardcode any wiki page in message strings. . . .
Note that English-language special page names will work on wikis in any language. However, that's probably bad to rely upon from an interface perspective, because some poor Chinese user or whatnot will see a bunch of Latin gibberish as the link target, I guess. Perhaps it would be ideal if all special-page names were universal, assuming that causes no conflicts. Then everyone could see the special page names in their own language in the interface.
- Furthermore there is a big inherent communication problem with interface
related changes in mutilingual wikis. If you changed an let us say legal message string in the default language people using another language won't notice it. Currently you'd need to overwrite every language-code sub page by hand in order to make people aware of the change (more than 80 edits needed for just one single message in order to cover every supported language). This specific problem has been covered as well by http://bugzilla.wikimedia.org/show_bug.cgi?id=8188 and is a severe showstopper to the success of projects like Wikimedia Commons. Several solution ideas and solution-side-effect problems have been discussed in this bug (my proposed solution with the changed message string resolution order would work now much better, as default messages are now deleted in mediawiki namespace).
I've already commented there, of course.
All these problems are currently big problems for multilingual wikis but can be solved in Mediawiki without need for some revolutionary magic code mix-up, just step by step with fairly small code changes. Fixig these issues would be a great leap forward for multilingual wikis.
You'd help some struggeling Wikimedia wikis a lot.
I agree, most of these wouldn't be terribly difficult to do and would be a big help. Maybe I'll keep them (at least the easier ones :) ) in mind for some rainy day in the future.