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(a)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.