Hoi,
In the past I have urged for a better support for the translators who
work on the localisation of MediaWiki. I expressed that in BetaWiki we
have an environment where it is much easier for translators to work. It
does not require expert knowledge about thinks like Subversion and
Bugzilla. One added benefit is that many people can work on the
localisation of MediaWiki for the same language making it very much more
a Wiki approach.
I have asked Nikerabbit, who has been hosting the BetaWiki wiki, if it
were possible to make changes to the MediaWiki software available in an
extension. He has done so, and Brion permitting it can be implemented
elsewhere.
The reason for the extended list of recipients of this mail is, that in
my opinion the best place to concentrate the "SpecialTranslate"
extension is the Incubator. The reason is that when a project is being
prepared for a full project status, the localisation is very much part
of this preparation. With the localisation being part of the incubation,
the work done will be preserved when it moves from incubation to
production. Also it provides instant gratification while it is still in
the incubator stage.
For the other projects, it is as good a place as any. Having it in
Incubator concentrates the localisation effort and for the benefits this
provides I would propose to do all the localisation using the
SpecialTranslate in Incubator.
Finally I want to thank Nikerabbit both for hosting BetaWiki and for
modifying the software so that we can have it as part of a WMF project.
Thanks,
GerardM
As part of the general fix for bug 5827, I've made some changes to the
message use in the watchlists in r18632.
We used to construct the label texts for things like "show own
edits"/"hide own edits" using a combination of a "show" or "hide"
message, and a partial link combination. This was bad for
accessibility and bad for usability and probably not too friendly for
internationalisation either.
We now use full messages as label texts:
* watchlist-show-own
* watchlist-show-bots
* watchlist-hide-own
* watchlist-hide-bots
I anticipate that I'll be poking this for recent changes itself (since
that's what the bug was filed against), and recent changes linked;
sometime this week.
Rob Church
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=Arnomane&t…
(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
Moin,
I am wondering, whether it really is correct, that there is no documentation of
function or use of the single MediaWiki messages? If you try to translate
messages without knowing anything about their context, this really is hard. Is
there anywhere in this big wiki world any page, where I at least can see, which
Special pages or whatever use these messages?
Slomox
Marcus Buck
Within the next fortnight, I plan to commit a set of changes which
will allow the multiple-language internationalisation of extensions
I've written, including:
* BadImage
* GiveRollback
* Makebot
* NewestPages
* Patroller
* ProfileMonitor
* UsernameBlacklist
It's quite simple to provide a translation for these; reading one of
the .i18n files will make it quite clear how. I use the same base
mechanism as other translated extensions, but with trivial differences
in how the translations are read out before feeding them into
MediaWiki; this allows me to keep most of the extensions backwards
compatible, where appropriate, which was one reason I didn't like the
method that's been used before.
You are, of course, quite welcome (and encouraged) to provide
translations for these extensions, and to post patches on BugZilla or
pester an existing committer to add them.
If I change the semantics or handling of a message in English during
an update, or I change, e.g. the parameters passed to it in an
incompatible manner, then I'll comment out the translations. This will
cause the fallback language to be used so that the code continues to
*work*, but to be honest, I don't envision making huge changes to
existing extension code; I'm more likely to *add* something.
Cheers,
Rob Church