What: i18n triage bug triage When: Wednesday, August 31, 15:00UTC Time zone conversion: http://hexm.de/6h Where: #wikimedia-dev on freenode Use http://webchat.freenode.net/ if you don't have an IRC client
Siebrand and Niklas and I spent time yesterday to prepare an i18n triage for Wednesday. The following bugs will be discussed. I would specifically call for any Arabic-knowledgeable developers to come to this triage for #21429 ("Arabic double diacritics presentation"). If you know someone who could help us with this bug, please invite them to come to the triage or, at least, look at #21429.
https://bugzilla.wikimedia.org/164 -- Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/24156 -- Messages of log entries should support GENDER
https://bugzilla.wikimedia.org/2361 -- Support dynamic fonts (CSS 3 @font-face, ttf/otf/eot, web fonts, WOFF) (done?)
https://bugzilla.wikimedia.org/29000 -- Allow font selection by language
https://bugzilla.wikimedia.org/29005 -- Unnecessary unicode Char code change
https://bugzilla.wikimedia.org/29318 -- Pack the list of available fonts
https://bugzilla.wikimedia.org/4030 -- EasyTimeline reversed text in RTL languages
https://bugzilla.wikimedia.org/29495 -- Numbering system grouping for Indian languages
https://bugzilla.wikimedia.org/21429 -- Arabic double diacritics presentation
I hope to see a lot of you there!
Mark.
On 30/08/11 19:59, Mark A. Hershberger wrote:
https://bugzilla.wikimedia.org/4030 -- EasyTimeline reversed text in RTL languages
isn't there a plan to replace EasyTimeline with something new? If so it is probably not worth investing time in this bug.
On Tue, Aug 30, 2011 at 11:54 AM, Ashar Voultoiz hashar+wmf@free.fr wrote:
On 30/08/11 19:59, Mark A. Hershberger wrote:
https://bugzilla.wikimedia.org/4030 -- EasyTimeline reversed text in
RTL
languagesisn't there a plan to replace EasyTimeline with something new? If so it is probably not worth investing time in this bug.
I don't think there's an active plan, but I'd love to replace it with something that produces SVG natively, skips over the scary perl code and shell-out to ploticus, and allows for interactive editing int he browser. :)
-- brion
On Tue, Aug 30, 2011 at 10:59 AM, Mark A. Hershberger < mhershberger@wikimedia.org> wrote:
https://bugzilla.wikimedia.org/164 -- Support collation by a certain locale (sorting order of characters)
The main problem here seems to be that you can't *use* a locale- or language-specific collation without writing additional custom code to support one -- so it's not quite possible for the site administrators to actually enable it on request or by default and batch-update the sort key tables.
For example: bug 29788 "Sort Swedish letters ÅÄÖ correctly on Swedish Wikipedia" https://bugzilla.wikimedia.org/show_bug.cgi?id=29788
It kinda looks like all the infrastructure is there to use ICU's collations for any supported locale, except that only 'root' (UCA default) ever gets passed into the constructor; it sounds like it should not take a *lot* of code to automatically slurp in the appropriate language if available/configured.
Secondary problem is that the fixes implemented so far only work for category listings, which is a tiny subset of things that get alphabetically sorted and displayed. The biggest other ones are likely page listings in Special:Allpages, Special:Prefixindex, Special:Listusers, etc.
(Personally I've never considered any of this too huge a problem overall as we have primarily search-driven interfaces, not browse-a-giant-list-of-hundreds-of-thousands-of-pages interfaces; traditional alphabetic indexing is a random-access assist and, for long lists, is mostly replaced by keyword searching and typeahead suggestions today. But those alpha lists do exist still, and they're consistently sorted incorrectly, without even touching the collation support we now have. Should at a minimum open up a new bug for those so it doesn't get forgotten.)
Tertiary problem is that things like the client-side table sorter also don't get the benefit of the server-side collation support. (This should be split out into a separate bug; table sorting does now have some basic support for alternate-sorting arrangements but its collation table replacement approach is probably not sufficient to provide more general sort compatibility)
-- brion
wikitech-l@lists.wikimedia.org