Hoi,
We now have a procedure on how we can get new language files in the
Incubator. What we now need is to know is if people want to start with
the English language for their initial start or with another language.
We can imagine that you want to start for Ottoman Turk with either Arab
or Turkish. For Palatinate German it could be better to start with German.
Please let me know within a week what you want for this and we will
accommodate you in this way.
For the Kabyle language we will use the work that is currently done in
BetaWiki. It is not sensible to start with a Kabyle file now in the
Incubator. We do not want to do things twice..
Thanks,
GerardM
Hello, bon jour, guten tag, saluton, etc.
I can't greet everyone fairly, because I don't speak 200-odd languages.
Unfortunately, MediaWiki doesn't, either, and that's what this email's
all about.
I'm well aware that foundation-l has had a recent, er, "heated
discussion" about internationalising the software with respect to
starting new wikis, and I'd rather not stir up a beehive with regards
to that.
We've got some fantastic people working on the internationalisation
front for MediaWiki; credit must go to Niklas Laxström for his
patient, unending work in this field. I'd also like to mention Rotem
Liss, who has been providing updates for the Hebrew language for a
long period, now, as well as our volunteers giving us updates in
German, Russian, Chinese and Japanese; a big, firm "thanks" is in
order.
The problem is that we don't have all the bases covered; there are
vast numbers of languages not being maintained, and that's a bit of a
problem for a software product that's supporting an organisation with
international goals in mind.
While individual communities can and do perform translations in their
MediaWiki namespaces, reliance on this means that each new wiki we
launch needs to perform this step, as opposed to having the interface
available in their language, from the fore. I believe that not having
software that speaks to you in your language is an immense barrier to
contribution.
I'd therefore like to rally a call to arms; we need translators!
Thanks to (again, what an i18n legend this dude is) Nikerabbit's work
on Betawiki (http://nike.users.idler.fi/betawiki/) means we will (I
hope) soon have a clean extension on the Wikimedia Incubator which
will make this stuff easier; it's the same process as editing the
MediaWiki namespace now, except what we get out of it allows us to
tweak and bundle up the translations into the right form for MediaWiki
to use.
Of course, if you're able to get to grips with our message file format
and you can work a Subversion client, you are more than welcome to
update the localisation for your language, or indeed, any other
language you feel you can contribute to, and submit patches. If you
submit on a consistent and regular basis, then commit access is also
forthcoming - we're grateful for people who can speak languages we
can't, who can help us out in a major area.
Contributions to MediaWiki internationalisation fall under the GNU
GPL, which is for all intents and purposes, ideologically similar to
the GNU FDL. If you are the maintainer of a language, you will be
credited for it, and you *will* have our immense respect and
gratitude, as well as that of all our users.
There's a guide to getting started with internationalisation at
http://nike.users.idler.fi/betawiki/Translating:Intro, and anyone
interested in helping out is strongly recommended to contact (look,
shall we just make him the official i18n co-ordinator?) Nikerabbit;
who can often be found on IRC (#mediawiki, irc.freenode.net).
Thank you for your attention, and I apologise for cross-posting,
Rob Church
MediaWiki developer
Please, look at my patch.
http://bugzilla.wikimedia.org/show_bug.cgi?id=9392
It is Russian translation patch for several Mediawiki extensions.
Is it good to create one patch for several extensions?
What "component" (from list in bugzilla) should I select?
--
Kunlabore,
Alexander Sigachov
Hello,
Please compare
http://commons.wikimedia.org/w/index.php?title=Special:Userlogin&uselang=he…
to
http://he.wikipedia.org/w/index.php?title=Special:Userlogin&uselang=he&type…
On Commons, the messages appear RTL text direction which is correct,
but on the left, which I imagine is as unnatural as right-aligning for
English.
Evidently there is some sitewide setting for he.wp that tells it to
display messages right aligned. Commons default language is English
which is left aligned. I guess that using uselang=he is not enough for
it to display messages right aligned?
Should we (Commons) go and insert <span align="right"> around every /he message?
Would this solve it?
(Would this be a *good way* to solve it?)
thanks,
Brianna
user:pfctdayelise
Hi list,
Most of you did probably read that thread (embedded links in UI messages
(splitted from "Major flaws...")):
http://lists.wikimedia.org/pipermail/wikitech-l/2007-January/thread.html#29…http://lists.wikimedia.org/pipermail/wikitech-l/2007-February/thread.html#2…
(Please read it in order to understand the following)
I now have fixed the internal links in MessagesEn.php and all Message files
from A to C (except MessagesAr.php which will follow later).
So my work resulted in these style guidelines for translations:
1) Do not use local namespace names in standard message strings. The same
applies for localised wiki markup (like translations of "thumb" and such).
Especially something like "Benutzerseite von [[Benutzer:$1|$1]]"
(German "user page of ...") instead of "Benutzerseite von [[User:$1|$1]]" is
dangerous as the link does not work in wikis with a different name for user
namespace (basically all wikis with a default language other than German,
canonical namespace links get translated to localised, use {{ns:user}} and
such when not using alternative link text or text outside links).
2) Do not link article namespace images or or other local content. Something
like "Your [[IP adress]] has been blocked..." is wrong. It has to be "Your IP
adress has been blocked...". No other wiki than Wikipedia or a wiki on
networking will usually have an article about IP adresses.
3) No Cross-wiki/interwiki links. Especially links like "[[w:en:IP adress]]"
are not allowed as well as interwiki link definitions into Wikimedia wikis
are removed in default MediaWiki.
4) Do not directly link any project pages in messages. Use only the link
definitions such as {{MediaWiki:helppage}}. Do not create new link
definitions in your local MessagesXX.php file.
As you probably can imagin fixing all 151 message files takes quite a while
and thatfor I call for your help. As well I wasn't able to fix every link
(tagged with '# problem with link' in message files). So please retranslate
them now.
The broken strings in desparate need for translation are so far (just the
Message files from A to C):
MessagesBe.php
* 'blockiptext'
* 'copyrightwarning'
* 'protectedpagewarning'
* 'uploadtext'
MessagesBg.php
* 'protectedtext'
* 'newarticletext'
* 'protectedpagewarning'
* 'protectlogtext'
MessagesBpy.php
* 'blockedtext'
MessagesBr.php
* 'protectedpagewarning'
* 'recentchangestext'
* 'uploadtext'
* 'confirmdeletetext'
* 'protectlogtext'
* 'blockiptext'
MessagesBs.php
* 'blockiptext'
* 'confirmdeletetext'
* 'newarticletext'
* 'noarticletext'
* 'noexactmatch'
* 'protect-text'
* 'protectedtext'
* 'protectlogtext'
MessagesCa.php
* 'protectedtext'
* 'uploadtext'
MessagesCs.php
* 'uploadtext'
* 'blockiptext'
MessagesCsb.php
* 'recentchangestext'
* 'uploadtext'
MessagesCy.php
* "protectedtext"
* "protectedpagewarning"
* "uploadtext"
* "protectlogtext"
That's all for now.
Have fun,
Arnomane
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