Sorry, I was supposed to send this on Friday evening already.
The highlights of the next i18n deployment:
* Enabling Translate on mediawiki.org
* Updating Narayam and WebFonts to latest versions. Please test them
in translatewiki.net
** Menu appers only on click, not when hovering
** Menu positions correctly in RTL and does not go offscreen.
* Language name for Veps updated
Also a couple of smaller fixes, that can be found at:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/i18ndeploy
Deployment will happen between 1800 and 1900 UTC
-Niklas
Highlights of the next Monday's i18n deployment (18-19 UTC):
* We are going to enable WebFonts in selected Indic language projects
and in incubator.
* We are updating Narayam to latest version: new features include:
more mappings, improved UI and support for modern and monobook skins.
* Babel no longer prefers local templates over built-in language boxes
- this make co-existence of old and new babel system less of a
problem.
* Solved cropping of text issues in headers for many Indic languages
Full list of revisions (except those of Narayam and WebFonts) is at
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/i18ndeploy
-Niklas
I had an idea for a feature to allow any language user to go to any other
language wiki and be able to use the namespaces they recognize.
The idea would be that a user from it.wp could go to fr.wp and when
visiting Utente:... (Utente is User in Italian) whether via search or
direct address linking and end up on Utilisateur:... (French's User
namespace)
This would be done by considering every possible localization of a
namespace as an alias in all languages. So on fr.wp Utente, User, etc...
would all be aliases for Utilisateur. Additionally since namespaces are
dependent on the user rather than the content for logged in users we could
start displaying localized namespace names to help the user around and not
have to worry about issues that if they copy&paste or whatever it wouldn't
be valid.
We've got a massive localization cache, and it's possible we might find a
way to make a feature like this possible, so that wasn't an issue to stop
this idea. But there was a slim possibility that words used for namespaces
might conflict with what other languages use. That sounded so unlikely
that I wrote a script to scan every language we have for all available
namespace names and what they map to and see if the same text is used for
different namespaces in any languages.
And the dooming news, there are some conflicts.
"Stampa" is NS_TEMPLATE in Aln (Gheg Albanian) and Sq (Albanian) and
NS_FILE in Mt (Maltese). And Datoteka is NS_FILE in Bs (Bosnian), Hr
(Croatian), and Sh (Serbocroatian), but NS_MEDIA in Sl (Slovenian).
So our only options are (probably in order of simplicity/likelihood first
;) ):
A) Drop this feature idea.
B) Find a way to deal with collisions and accept there may be some bugs an
confusing behavior for users.
C) Implement this while making use of lots of language heuristics like
Accepts-Language, Geolocation, and other things that will hurt caching.
D.a) Drop support for either Maltese or Albanian languages and Slovenian
or Croatian languages.
D.b) Convince everyone who speaks these languages to use a different word.
D.c) Commit genocide and wipe those languages off the face of the earth
and erase them from the history books.
E) Implement a brain-neural interface and require use of it while browsing
Wikipedia so that we can extract what the user 'actually' means and
understands directly from their mind.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Next Monday (1800-1900 UTC) the L10n team is planning to deploy the
following revisions:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/i18ndeploy
Summary of the revisions:
98140 102786 - Babel: Possibility to use the language code as
parameter on categories.
102777 Use protocol relative links in messages when possible (merged
to allow l10n update to pick up translations)
100023 Category tree: improved display of category contents with better i18n.
CCing Mediawiki i18n list from now on.
-Niklas
Dear subscriber to mediawiki-i18n,
I would like to invite you to the Localisation Development Showcase on
2011-11-14 at 17:00 UTC. This meeting will take 40 minutes at most. In this
meeting the Localisation team will present its progress made during sprint
2 of release 1.
We hope you can attend, and please invite any other colleagues or friends
you think would appreciate being present! This meeting will be recorded,
and made available to you online, so that you can view it at a more
convenient time if you like.
Our previous showcase can be found at
https://commons.wikimedia.org/wiki/File:Localisation-team-showcase-20111031…
open format) and
http://translatewiki.net/static/showcase/. The native .arf format requires
a WebEx viewer available at
http://www.webex.com/play-webex-recording.html(Windows/OSX only).
Siebrand Mazeland
Product Manager Localisation
Wikimedia Foundation
-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://wikimedia.webex.com/wikimedia/j.php?ED=164734027&UID=1226678982&RT=…
2. If requested, enter your name and email address.
3. This meeting does not require a password.
4. Click "Join".
To view in other time zones or languages, please click the link:
https://wikimedia.webex.com/wikimedia/j.php?ED=164734027&UID=1226678982&ORT…
--
Siebrand Mazeland
Product Manager Localisation
Wikimedia Foundation
M: +31 6 50 69 1239
Skype: siebrand
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hi,
While reading a bug pointed by the i18n triage
<https://bugzilla.wikimedia.org/show_bug.cgi?id=16026>, Happy-melon says
"A more general bug (which might well exist, I didn't check thoroughly)
would be "ALL MediaWiki messages should be either plaintext or accept
wikimarkup."
So I had the idea of censusing the wfMsg calls in the MW code and try to
detect which ones accept wikimarkup or other dialects (it depends of the
wfMsg function and of the parameters of that function). So I wrote
yesterday a Python script to census the wfMsg calls in one side and the
messages in another side. The latter is not very useful in fact but the
former gives some interesting results.
I’ve done some statistics about the wfMsg calls on
<http://www.mediawiki.org/wiki/WfMsg_statistics>. There are also the raw
data and the link to the script (output to CSV).
If you find it useful I would be happy, but it was also an exercise for
extracting and manipulating data.
Seb35
Please find below the notes for the internationalisation triage bug
triage held on Wednesday, September 14, 13:00UTC in #wikimedia-dev on
Freenode IRC.
9 people participated in the triage. Two of the participants were new
to MediaWiki. I'm very happy that the triage attracted new potential
MediaWiki developers!
The triage was to have have two sections, each taking about 30 minutes.
We ended up with a "first half" of about 55 minutes and a second half
Of about 20 minutes.
Next week's triage is on WikiBooks
http://www.mediawiki.org/wiki/Bug_management/Triage
== Message documentation and message related coding ==
https://bugzilla.wikimedia.org/show_bug.cgi?id=16026 --
MediaWiki:Revision-info should accept wikimarkup
* Volunteered by Amir.
https://bugzilla.wikimedia.org/show_bug.cgi?id=16111 --
MediaWiki:Cascadeprotected and MediaWiki:Cascadedprotectedwarning should
take the same parameters
* Volunteered by Amir.
https://bugzilla.wikimedia.org/show_bug.cgi?id=16175 -- Clean up the
rendering of messages displayed at the top of the edit window
* Volunteered by Amir. May be a difficult one, as these messages are
used a lot in Wikimedia projects.
https://bugzilla.wikimedia.org/show_bug.cgi?id=17148 -- The warning about
editing a semi-protected page can display an irrelevant edit summary
* Volunteered by Brian Wolff
https://bugzilla.wikimedia.org/show_bug.cgi?id=17865 -- Mismatched input
syntax for Cite error messages
* Some discussion. Cite is seen as scary! No one to take this yet.
Please give this some TLC.
https://bugzilla.wikimedia.org/show_bug.cgi?id=28557 -- Message
documentation for Extension:AddMediaWizard needed
* Volunteered by Blucal.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25608 --
MediaWiki:Fundraiserstats-tab-ytd should not contain (USD)
* Goes to fundraising triage. A concern was voiced that i18n does not
appear to get the attention it needs. The Localisation team will get
in contact with the fundraising developers when they are in San
Francisco in two weeks to discuss..
https://bugzilla.wikimedia.org/show_bug.cgi?id=29357 -- CategoryTree
should have built-in localizable support for pretty Categorytree-member-num
* Amir volunteered for this. Brian is prepared to help him out where
needed.
https://bugzilla.wikimedia.org/show_bug.cgi?id=29927 -- CentralAuth using
wrong Language on Special:MergeAccount
123456789012345678901234567890123456789012345678901234567890123456789012
* Akshayagarwal volunteered for this, and has committed changes in
<http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97168>
https://bugzilla.wikimedia.org/show_bug.cgi?id=30729 -- Not all numbers
are localised in AbuseFilter
* srikanthlogic has volunteered for this with Brian Wolff as mentor.
https://bugzilla.wikimedia.org/show_bug.cgi?id=29170 -- [[MediaWiki:Enotif
body]] needs GENDER support
* Some discussion, but nothing final.
== Harder issues and discussion ==
https://bugzilla.wikimedia.org/show_bug.cgi?id=28428 -- Allow saving pages
with LRM and RLM in titles, showing a warning and requiring a user right
https://bugzilla.wikimedia.org/show_bug.cgi?id=28411 -- titles of articles
with LTR titles in RTL wikis may be displayed incorrectly in categories
and special pages
* It looks like a schema change is not needed, and that the
page_props table can and should be used. Use batches where needed;
integrate that in Linker, LinkBatch and probably Title as well.
Ambitious according to Roan. Roan agrees that having displaytitle as a
page_ field makes more sense *conceptually*. In practice, he prefers
page_props because that avoids a schema change and is still cheap.
Niklas indicated the discussion gave him ideas on how to work towards
resolving these issues.
The other announced issues were not discussed.
Thanks to everyone participating. Looking forward to the results!
--
Siebrand Mazeland
Product Manager Localisation
Wikimedia Foundation
M: +31 6 50 69 1239
Skype: siebrand
Hi,
Messages such as these:
* MediaWiki:Pfunc-convert-unit-length-metre
* MediaWiki:Pfunc-convert-unit-length-angstrom
* MediaWiki:Pfunc-convert-unit-length-mile
all have a problem: they only take the plural of the word itself, but
the number is left out. For example,
MediaWiki:Pfunc-convert-unit-length-mile is {{PLURAL:$1|mile|miles}}.
Usually in such messages the number itself is not only an argument,
but also a part of the return value and for a good reason: in some
languages one is treated differently from plural. For example, in
Hebrew the number 1 comes after the noun and all the other numbers
come before it.
These messages must be re-written as {{PLURAL:$1|$1 mile|$1 miles}}.
In Hebrew it would be something like {{PLURAL:$1|mile $1|$1 miles}}.
Thanks.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore