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.
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
