For anyone who has doubts about the efficacy of bug triages, I offer this observation that Siebrand made about the triage in IRC:
I loved this triage! Brilliant. And I really liked we didn't get stuck in 164, it allowed us to cover everything we had prepared and more.
Anyway, this was a pretty good triage. We focused on a small subset of the over 100 bugs tagged with "i18n" and still managed to go over the allocated 1hr for discussing things.
A couple of bugs were added to the triage since I sent out my announcement, so I'll just use the etherpad (http://etherpad.wikimedia.org/BugTriage-2011-08) for this report:
https://bugzilla.wikimedia.org/164 -- Support collation by a certain locale (sorting order of characters)
We decided this one should be broken up into three separate tracking bugs and a fourth bug for one specific issue:
https://bugzilla.wikimedia.org/30672 -- improve sorting on other pages than category pages (tracking) https://bugzilla.wikimedia.org/30673 -- Support locale-specific, or tailored, sorting (tracking) https://bugzilla.wikimedia.org/30674 -- Support better client-side sorting (tracking) https://bugzilla.wikimedia.org/30675 -- Use allkeys_CLDR.txt - the CLDR tailored DUCET instead of allkeys.txt
https://bugzilla.wikimedia.org/24156 -- Messages of log entries should support GENDER
Although I requested a UX designer to join us for this bug, apparently there was a scheduling problem. As a result we continued the triage on the assumption that the format of the RC and log pages will not change in the future.
After some discussion about the scope of the work needed, Niklas pointed out that the log messages were implemented differently and he would like to bring some sanity to the underlying code. Niklas said he would start on the work after he was satisfied that he could get someone to review his design and code.
https://bugzilla.wikimedia.org/29000 -- Allow font selection by language
Krinkle and Santhosh discussed this bug heavily. Santhosh pointed out that the Webfonts extension can already load a font based on the user language and it could be adapted to load different fonts for the content language(s) where languages would be specified like <div lang="ar">.
This raised the question of how to scan the text -- should the text scanning happen server-side in PHP or client-side in JS, where there might be a "flash" as the appropriate fonts were loaded.
Finally, Niklas raised the issue of the sidebar which might have 100 different languages each with a different preferred font. To avoid loading 100 fonts, we'd need to figure out where a font was needed versus where the text would still be readable without it.
https://bugzilla.wikimedia.org/29005 -- Unnecessary Unicode Char code change
This one was taken care of with the discussion already on etherpad before the triage meeting. It is dependent on a Unicode issue with the Malayalam language. Santhosh is talking with Indian government agencies. He has prepared a report on this (and some other issues) - to be submitted to the Unicode Technical Committee.
https://bugzilla.wikimedia.org/4030 -- EasyTimeline reversed text in RTL languages
We were mostly looking for a Perl developer to take this over. Since Amir had experienced the pain of this particular problem ("in Hebrew we actually have to write the words in reverse") and has Perl knowledge, we gave him full reign.
https://bugzilla.wikimedia.org/29495 -- Numbering system grouping for Indian languages
Santhosh had already outlined the relevant specifications. When Niklas asked if we could use the Common Language Data Repository (CLDR, http://en.wikipedia.org/wiki/CLDR), Santhosh pointed out that it was incomplete. Siebrand responded that since Wikimedia is a member of the Unicode Consortium now, completing the CLDR is actually feasible.
https://bugzilla.wikimedia.org/21429 -- Arabic double diacritics presentation
This looked like it was mostly an issue of presentation, not any RTL issues. Since we lacked any Arabic developers in our triage meeting, Amir volunteered to bring this up next month at a meeting that Wikimedia Israel had scheduled with some Arabic developers.
https://bugzilla.wikimedia.org/29671 -- Use user-language names of Special pages in the URL
After a small bit of discussion, everyone agreed to WONTFIX my pet bug.
As Niklas said in the comments on the bug: "URLs are kind of sacred area, intended for both humans and computers. I'd avoid doing anything overly clever there."
https://bugzilla.wikimedia.org/30130 -- Narayam does not work properly on Chrome browser
Siebrand started discussion on Narayam and getting it re-enabled for the Tamil wiki projects (https://bugzilla.wikimedia.org/29798). This issue was the only blocker for that. Santhosh is to implement a webkit-only workaround for Narayam since the upstream bug (http://hexm.de/6m, http://hexm.de/6n) and related WHATWG discussion (http://hexm.de/6o -- featuring our own Aryeh!) point to long-standing issues in Webkit's handling of things.
Since the webkit problem is the only one remaining with Narayam deployment, I've asked that it be redeployed for Tamil projects.
Thanks to all who participated in this week's triage. Next Wednesday: Download Wizard.
Mark.