[14:44:08] Hi. Well. After I unified my account after user rename my contributions returned to the old username (or at least some of them) - Can this be fixed? [14:44:23] triage in ~15min [14:44:41] mafk: ask in #wikimedia-operations ? [14:44:48] mafk: Yes. File a bug in Bugzilla with the details (wiki, new name, old name, etc) [14:45:16] RoanKattouw: merci bien. J'espere qu'on trouve un solution :) [14:48:17] Ce n'est pas la premi??re fois que les contributions d'un utilisateur r??nomm?? n'ont pas le nouveau nom, ce passe quand l'utilisateur a milles de contributions [14:49:42] J'avais +20.000 [14:54:11] Bug FIGHT: https://bugzilla.wikimedia.org/show_activity.cgi?id=12145 [14:54:26] triage in 5 min! [14:55:00] Present. [14:55:08] Present. [14:55:58] hexmode: on 12145: nah, just submitting a new attachment with L10n (or localization) updates over and over... [14:58:14] RoanKattouw: fait https://bugzilla.wikimedia.org/show_bug.cgi?id=30661 [14:58:38] siebrand: claudia found it was the one that went resolved->reopened the most [14:58:51] mafk: Parfait [14:59:02] :) [14:59:21] hexmode: *nod* Can be ignored, as this was misuse of the functionality. Each re-open was really new bug creation [14:59:31] Avec 'shell', tracking bug, tout est l??. Merci [14:59:48] CC "ariel" [15:00:01] 1min [15:00:10] *hexmode sends email to claudia [15:00:32] Etherpad for the bug triage: http://etherpad.wikimedia.org/BugTriage-2011-08 [15:00:41] hi santhosh [15:00:51] sumanah: Hi! [15:01:39] hello everyone [15:02:03] hi everyone. Thanks you for being here. [15:03:46] so, lets starat [15:03:48] start [15:04:19] Do we have a good idea how to break up #164? [15:04:24] !bug 164 [15:04:24] --elephant-- https://bugzilla.wikimedia.org/show_bug.cgi?id=164 [15:04:45] AryehGregor: ping [15:05:03] santhosh: aryeh is not available. Per e-mail he suggested: [15:05:19] Some things that have been brought up. These seem to be the major issues that people are discussing at this point in the bug: [15:05:20] Support the better sorting in places other than categories, like special pages. [15:05:21] Support locale-specific (tailored) sorting, different for different wikis and/or different categories, not just UCA default. [15:05:22] Support better client-side sorting. [15:05:47] If you tell me how to break it up, I'll file the separate bugs... but I want to make sure I get them all [15:05:50] santhosh brought up: Should we consider using allkeys_CLDR.txt - the CLDR tailored DUCET instead of allkeys.txt? [15:06:08] siebrand: we need a seperate bug for client side sorting. especially sortable tables [15:06:23] in #164 , there is a big discussion on that side in last comments [15:06:36] Yes, that is apparent to me, too. [15:06:40] apparently there is an attempt going on as well by the author of that comment [15:06:41] bug: support better sorting on special pages -- which onex? [15:06:58] santhosh: it sounds like its a long way off though [15:07:02] So Aryeh suggested 3 categories of issues. Are there any issues that need more fine grained split-ups? [15:07:08] Verdy tends to be mostly talk on most bugs [15:07:43] let's not be too distracted by the tl;dr. [15:08:01] "mostly talk" --- big big essayist [15:08:23] so close it and open 3 seperate bugs [15:08:25] ? [15:08:41] each would be a tracking bug, I think? [15:08:52] hexmode: how about one more bug for santhosh suggestion? [15:08:54] hexmode: that's not a bad idea, hexmode [15:09:11] Nikerabbit: 4 bugs then [15:09:17] Going once... [15:09:39] santhosh's suggestion is not tracking, right? [15:09:42] hexmod, As AryehGregor suggested, we need to figure out using tailored data than DUCET for more accurate sorting results [15:10:01] that should be a bug, mainly to investigate the options there [15:10:09] ok [15:10:18] Moving on [15:10:30] Trevor didn't show :( [15:10:41] secondly, a bug for client side sorting [15:10:47] jorm: have a little time? [15:11:07] Nikerabbit: what are the others? [15:11:07] jorm: https://bugzilla.wikimedia.org/24156 -- Messages of log entries should support GENDER [15:11:39] santhosh: They're on the etherpad, I think, right? [15:12:08] yes, fine . that will do [15:12:10] no jorm .... :( [15:12:38] mm [15:12:47] So #164 is split up in 3 tracking bugs: (1) improve sorting on other pages than category pages (2) Support locale-specific (tailored) sorting (3) Support better client-side sorting, and non-tracking bug, change request (4) Use allkeys_CLDR.txt - the CLDR tailored DUCET instead of allkeys.txt [15:13:43] Well, we mainly asked a UX designer, because we wanted to know if the list form of log and RC pages was the future, too. In Berlin during the hackathon, I think I heard talk about making these pages tables. [15:13:44] apart from gender, log entries should support variable word ordering [15:14:05] We can continue assuming the format does not change. Is that OK? [15:14:28] sounds fine to me [15:14:39] not in near future I'd guess [15:14:51] Krinkle: https://bugzilla.wikimedia.org/29000 -- Allow font selection by language [15:14:56] and in any case we should store the parameters (instead of the formatted message), which not all logs do IRCC [15:14:59] any thoughts? [15:15:05] *Krinkle is here :) [15:15:16] OK. The issue here is that we basically need the actor to be taken into account when creating the list lines. [15:15:38] Now a username is always given first, and then some log entry message follows. [15:16:02] "taken into account" -- clarify? [15:16:04] There is no difference in phrasing for gender of that user(name) [15:16:16] ah [15:16:30] * [15:16:34] Instead of: [15:16:52] * [15:17:15] is amir here? [15:17:17] Is that the essence of the issue? [15:17:36] siebrand: you're suggest we switch to "" ... right? [15:17:43] siebrand: from this point of yes [15:17:58] my biggest issue is that the code is mess and different logs are implemented differently [15:18:04] point of view* [15:18:11] code refactoring time [15:18:38] also another bug for "code quality issues" ;) [15:19:11] Do we agree this is needed for proper i18n, and is it doable, or will it be a big mess? [15:19:26] Can it be change gradually, or is it "big bang"? [15:19:31] change = changed [15:19:37] so... restructuring and making the code sane is very hard, while someone could with little effor make it more mess and hack the username parameter (fixing the word order issue is a bit trickier) [15:20:19] siebrand: it might be possible to do it in steps, because we need to keep BC to old log entries [15:20:21] *hexmode hates big bangs [15:20:30] What is the recommended action from here? Nikerabbit ? [15:20:52] siebrand: I think we all agree it needs to be done [15:20:56] Nikerabbit: could you outline what you think the steps should be? [15:21:51] Nikerabbit: if you can come up with several discrete, doable steps, maybe we can divvy up the work better [15:21:54] hexmode: I would design a proper structure, write the code to handle it and one by one convert all log types to use it [15:22:28] how hard is "design a proper structure"? [15:22:38] That sounds sane and manageable as steps. [15:22:48] hexmode: not very hard [15:23:09] Who could'should do it? Is it i18n team, or GenEng? [15:23:38] and, with a good structure, code is straight forward, I assume. [15:23:56] some effort is probably needed to understand the current code too [15:24:01] siebrand: I think i18n [15:24:41] I could even volunteer, if someone promises to help me :) [15:25:00] Proposed summary: Doable: (1) design and implement a proper structure, (2) convert logging/RC code over to the new design one by one. Can be done by the i18n team (Nikerabbit). Comments? [15:25:14] trevor will help you ;) [15:25:36] hexmode: that's a commitment you just got? [15:25:46] Nikerabbit: I dunno about you but I find mw devs to be very helpful [15:25:59] haha :) [15:26:06] hexmode: I also find them very busy [15:26:11] siebrand: no. I'm just saying he'll do it! [15:26:29] ok, we're done with 24156. [15:26:33] Nikerabbit: how much help do you thitnk you'll need? [15:26:35] hexmode: I'll take that. [15:26:44] :) [15:27:00] https://bugzilla.wikimedia.org/29000 -- Allow font selection by language [15:27:19] Next bug (repeating) https://bugzilla.wikimedia.org/29000 -- Allow font selection by language [15:27:26] hehe, was just about to :D [15:27:31] ok, Krinkle, do you have any thoughts on that? [15:27:33] hexmode: I'd imagine I want someone to review my design and first patches [15:27:53] just to get second opinion and green light [15:27:53] Yes. Although I'm no expert on WebFont specifically, for fonts in CSS in general I have a few thoughts [15:28:28] Krinkle: Today we just added a feature to load fonts if there is a font-family style defninition anywhere in the page [15:28:32] Nikerabbit: I'll look over them if you like [15:28:41] hexmode: it's a deal [15:28:47] Krinkle: this will be similar to that. [15:29:05] I think we can even do a lot of this in core. Specifically, I'd recommend MediaWIki ships with a collection of fonts. And depending on the content / user language either none, one or two are loaded on the page. Pure CSS. [15:29:41] No flash [15:29:56] flash as in a visual blink that the font 'is there' [15:30:02] Krinkle: that doesn't solve on a page problem [15:30:22] Krinkle: the existing webfonts extension is capable of addressing this, if we just get a list of languages [15:30:26] Krinkle: if we have MW shipping with fonts, then we'll *REALLY* want to have different tarballs [15:30:45] hexmode: they're hardly larger than 1 or two small images. [15:31:03] 44M total [15:31:14] Krinkle: not exactly, complex script fonts are big [15:31:17] all fonts of WebFonts, most of them in 4 different formats [15:31:18] anyway, shipping is not what I care about, let's talk i18n/develoment :) [15:31:20] I think keeping it in webfornts is good [15:31:26] fair enough [15:31:33] also, my typing sucks [15:31:42] quak [15:31:56] but what is the use case for text appearing on a wiki page that is not in the content language and not in the user language, that the user is supposed to have an additional font file for ? [15:32:16] Krinkle: Wiktionaries [15:32:21] (part of this may fit in a different discussion that is named "Extensions that are part of the core distribution", let's not have that :P) [15:32:24] or an article about page about Chinese script giving examples [15:32:45] Okay, great :) [15:32:57] or basically any article on anything that has foreign name :) [15:33:18] foreign name in a language that cannot be rendered by the default font, that is. [15:33:26] yes [15:33:38] santhosh: is 29000 something that should be done in webfonts then? [15:34:09] hexmode: yes [15:34:19] I'd say that WebFonts is at least part of the solution, because it has the fonts [15:34:23] So I'd recommend the WebFont's javascript API has a method mw.webFonts.fixLang( ['nl', 'en', 'he', 'ar'] ); that will then see if those langs need a certain font, and if not loaded already, load it. [15:34:43] And make one call to that by default when the page is ready. [15:34:46] Krinkle: yes, it has equivalent methods [15:34:49] alreay present [15:35:05] and additional calls can be made by scripts inserting ajax content. [15:35:15] santhosh: How does it determine which langs need to be 'fixed' ? [15:35:24] I think we actually have two alternatives: let the user load fonts manually using a GUI or try to load them automatically in way or another [15:35:36] does PHP scan content ? does JS scan content ? Or content lang + user lang ? [15:35:46] js scan the content [15:35:49] User shouldn't know about any of this. [15:35:55] aharoni: hey Amir. Great to have you. [15:36:09] shalom everyone [15:36:14] Krinkle: that is of course better, assuming we can do it good enough without user intervention, can we? [15:36:16] aharoni: see hterpad URL in the topic. [15:36:27] find out all the nodes having lang attribute, see if it differ from user lang or content lang. [15:36:38] the configuraiton alreay has default font each language [15:36:50] I realize many people who speak languages that are non-Latin, over the years, simply have come to know a thing about this, but that's an issue not a feature :) [15:37:10] do we run the risk of loading 100+ fonts for the sidebar, even though the user can already see most of the scripts fine? [15:37:24] santhosh: So how come bug 29000 exists ? [15:37:30] with sidebar I mean interlanguage links [15:37:59] well, there should be a difference made between a lang that requires a font or looks better in a font. [15:38:11] I think the 'better' part is only justifiable for content/user lang. [15:38:18] Krinkle: but different users require different number of fonts [15:38:19] Any page-specific lang just needs to not be broken. [15:38:35] Nikerabbit: Yes, even different pages need different fonts. [15:38:53] santhosh: should 29000 be closed "works for me with WebFonts"??? [15:39:06] it doesn't actually work yet [15:39:10] it's doable with webfonts [15:39:12] Krinkle: a template with font-family='fontname' works now. [15:39:14] oh [15:39:21] it loads the specific font [15:39:25] unless we accept that as a solution [15:39:55] santhosh: Why ? Templates should use lang="" not a font. That's so wrong. [15:40:18] but what is requested is lang attributes in the templates, nodes should load font without font-family [15:40:21] yes [15:40:23] ie. WebFonts could have a different name of that font, or perhaps use a different font for a language. [15:41:40] So what is the status right now in WebFonts with interlanguage-links in the sidebar ? Does it theoretically load a lot of fonts for that ? [15:41:52] Krinkle: no. [15:42:07] I'm not saying we should, but why isn't it doing that ? [15:42:26] It does not load any font other than the default font for uselang [15:42:45] ok [15:42:49] so, I'm still confused: what does 29000 need right now? some JS added to webfonts? [15:43:13] santhosh: is the mapping of userlang to font in JS or in PHP ? [15:43:43] (and I'd like to move on, also) [15:43:48] hexmode: webfonts can do this. the confusion is if we depend on lang attribute, will we end up loading too many fonts. [15:43:50] Krinkle: JS [15:43:52] Ie. is there a difference in WebFonts between lang-x needs font Y or lang-x is-better-with font Y ? [15:44:12] Krinkle: santhosh: could you add comments to etherpad [15:44:14] ? [15:44:24] hexmode: will do. [15:44:30] santhosh: We'll talk later :) [15:44:34] interesting topic. [15:44:45] anyway, that bug will be fixed with WebFonts when the plans are ready. [15:44:53] I think https://bugzilla.wikimedia.org/29005 -- Unnecessary unicode Char code change has enough comments right now one etherpad [15:45:18] https://bugzilla.wikimedia.org/4030 -- EasyTimeline reversed text in RTL languages [15:45:19] +1 Krinkle: the solution is there, it just needs a bit more discussion [15:45:31] is easytimeline going to live on? [15:46:06] hexmode: i spoke to Siebrand and Erik Zachte in Haifa about easytimeline. [15:46:18] and? [15:46:48] it is used quite a lot at least in some projects. it cannot just be retired. [15:46:49] aharoni: what was the result of that? [15:47:09] aharoni: so what is the story of rtl support for it? [15:47:26] in Hebrew we actually have to write the words in reverse. [15:47:33] hah [15:47:48] ugh... [15:48:00] it's useful enough for articles about History, that some people are ready to go through this, but it should be better. [15:48:06] so anyway, [15:48:10] and now tell me there is a tool server tool to facilitate that... [15:48:11] that's probably worse than driving on the wrong side of the road... [15:48:36] it's in Perl, which i actually know quite well and i plan to look at it very soon. [15:48:37] so, we need to find a perl dev [15:48:41] me, me! [15:48:42] but: [15:48:48] oo! [15:49:01] in fact, IIRC, i already assigned it to myself. [15:49:19] *drumrolls* [15:49:20] *hexmode loves aharoni even more now that he knows aharoni knows perl [15:49:42] Perl rules. [15:49:59] hehe :) [15:50:10] but, maybe this extension should be rewritten in PHP; maybe it should use an entirely different graphics library; and maybe it should output SVG and not PNG. [15:50:34] the problem is mostly in the graphics library that it uses. [15:50:48] maybe something similar already exists somewhere in the internets? [15:50:51] aharoni: one suggestion, if you have plans for rewrite, pang-cairo is the right choice [15:50:56] hmm, I think I've seen that suggested before, and the conclusion was: PHP sucks... [15:50:57] pango* [15:51:07] santhosh, thanks. [15:51:13] maybe JS tools are a better option? [15:51:26] siebrand, i'm always happy to use Perl. very, very happy. [15:51:37] is it ok if we go over time? still a few bugs to discuss... [15:51:49] hexmode: yes. [15:51:55] ok with me [15:52:07] (but we still have 8 mins. playtime left!) [15:52:26] santhosh: https://bugzilla.wikimedia.org/29495 -- Numbering system grouping for Indian languages [15:52:54] I think santhosh already has a good handle on that [15:53:04] do you have *time* for it? [15:53:37] hexmode: yes, I will take. But time is a question. A few days delay is acceptable I guess :) [15:53:50] isn't there some sort of PHP implementation of LC_NUMERIC already? [15:54:19] If we can find that it would be usable, right? [15:54:33] hexmode: yes, we can figure out it from localeconf. But that is platform dependent. [15:54:51] hmhm [15:54:59] would CLDR be of use? [15:55:28] Nikerabbit: yes. but we will end up with incomplete CLDR [15:55:35] hexmode: time in i18n team: will be part of sprints, so resolving a bunch of issues, and developing new functionality will be planned. [15:55:47] other than getting the patterns, it should be simple additions to Language::formatNum? [15:56:32] santhosh: yes CLDR is incomplete, and if we had enough time we would actually make it better with our data [15:57:13] well, Wikimedia is a Unicode member now, so maybe we can do something about that now. [15:57:26] aharoni: while you're here, and as our resident RTL expert, do you know anything about "https://bugzilla.wikimedia.org/21429 -- Arabic double diacritics presentation" [15:58:20] siebrand: can we consider what we can do about that in our sprints or somewhere? [15:58:53] Nikerabbit: define "that" [15:58:57] hexmode, i already looked at that one. if i understand correctly, it's not so much about RTL, as about normalization and proper font rendering. i can try to play with it, though. [15:59:18] aharoni: you know any arabic-native devs? [15:59:26] siebrand: to help make CLDR better with our (future) data [15:59:40] hexmode, i know some over email. [15:59:57] i know what Shadda and Kasra are, which is already a good start :) [16:00:08] Nikerabbit: we can consider everything, and I think this may actually be valid for a sprint in the coming months. The idea is that santhosh and gerardm will take over unicode contacts from kaldari [16:00:09] :) [16:00:30] aharoni: I'm sure I know some arabic devs over email :P [16:01:05] siebrand: k [16:01:50] ok, looks like we discussed all issues we had on our list. [16:01:58] hexmode: actually, WM-IL scheduled a real-life meeting with Arab devs next month, and i'll participate in it. [16:02:06] Is there anyone interested in having a discussion on Narayam? [16:02:33] i have time and interest in Narayam. [16:02:50] nobody has taken on the idea to make the UI like trevor's proposal? [16:03:25] Our highest priority at the moment is getting it re-enabled on Tamil Wikipedia, where it was enabled before. [16:03:31] Nikerabbit: UI for??? Narayam? [16:03:43] yes [16:03:52] Nikerabbit: we have the code with us for that UI [16:03:55] which proposal? [16:03:55] we just need to merge [16:04:06] oh! [16:04:18] siebrand: the Menu like UI. I had shared the patch with you people already [16:04:45] http://www.gossamer-threads.com/lists/wiki/wikitech/230797 [16:04:54] I also discussed it briefly with jorm at Wikimania; or at least that I'd be needing some of his time to get a proper UI worked out. I didn't know there already was one. [16:05:17] http://www.mediawiki.org/wiki/File:Narayam-proposal-annotated.pdf is direct link [16:05:53] Right. Something like that, but I was thinking a little more radical, based on some suggestions I got from some participants from India. [16:06:19] that's only a proposal, after all [16:06:27] and does not include virtual keyboard [16:06:36] we're making a real effort to not use any of the content area when putting elements in the sidebar, and I think that is a waste of great overlay space. [16:07:16] soo, who is able to do good interfaces with JS? [16:07:23] aharoni: I look forward to seeing your reports of that meeting between Arab & Israeli developers! [16:07:46] I'm expecting there will be a huge number of keyboard mappings in the future, and the UI should be smart, in that used mappings appear at the top of the selection list, and maybe users should even be able to hide whole mapping groups, and such. [16:07:59] Nikerabbit: you will be soon. Mark my words :) [16:08:19] The new UI as per Trevor suggestion is available http://thottingal.in/wiki/index.php?title=Main_Page&setlang=ta We already have bugs to change the grouping structure [16:08:34] With on-screen keyboards, the need for a proper UI will only grow. [16:09:04] Thinking of the on-screen keyboard selection on mobile devices gives me a slight headache... [16:09:17] siebrand: I can do lot of things but Js interfaces is not really among those [16:10:02] Nikerabbit: I'm 38 and learn new tricks every day. Surely at 22 (?) you, being smarter and all :P, are able to exceed that exponentially :) [16:10:23] sumanah: me too, we are very excited about it. [16:10:43] siebrand: :D [16:11:03] santhosh: do you know what's currently blocking re-enabling of Narayam at ta.wp? [16:11:19] santhosh: IMO it's getting trunk version tested. [16:11:58] siebrand: there is a keymaping issues, that is not serious. But there is an annoying webkit bug making it not working in chrome [16:12:15] umm [16:12:23] somebody reported IE crashed recently [16:12:33] https://bugzilla.wikimedia.org/show_bug.cgi?id=30130 [16:12:51] santhosh: not working at all, or disruptive? [16:13:04] [16:28:14] srikanthlogic> An SOS from ta.wikipedia [16:13:04] [16:28:27] srikanthlogic> we find browser crashes on page load on IE [16:13:04] [16:29:09] srikanthlogic> http://p.defau.lt/?Y9jGV7tCoILmR23hzdff7g is the crash report IE generates upon crashing [16:13:08] siebrand: not working at all [16:13:18] santhosh: because if not working in one browser is it, that's not a blocker for enabling it, is it? [16:13:21] means its useless [16:13:47] santhosh: I see you've added a link to https://bugs.webkit.org/show_bug.cgi?id=66630 in https://bugzilla.wikimedia.org/show_bug.cgi?id=30130 [16:13:58] siebrand: well, if we can ignore chrome and wait for webkit bug to be resolved [16:14:06] santhosh: is there any way we can influence the priority given to resolving that issue? [16:14:40] more voting to the issue in the webkit bugzilla [16:15:12] and adding a tracking bug in chromium bugzilla to get more attention(this I will do) [16:15:43] do we know anybody who could influence webkit devs to get that on their radar? :o [16:16:52] did we lose hexmode? [16:16:58] What worries me is the reference to https://bugs.webkit.org/show_bug.cgi?id=15256 [16:17:05] sorry about that [16:17:08] That issue is 4 years old. [16:17:17] computer froze :( [16:17:26] And if it's linked to a 4-year old issue that's not resolved, this may not get resolved any time soon. [16:18:09] siebrand: we have a workaround solution, but that will make edits on big text very slow, even making the browser crash [16:18:11] santhosh: you write that there is a work-around, but that is inefficient. Can you elaborate? [16:18:22] right, you beat me to that :) [16:19:01] could we implement that work-around only when webkit is being used? [16:19:17] siebrand: any other issues with Narayam on tamil can be addressed without any issues. I will check with tamil friends too. [16:19:55] santhosh: OK. I'd really like to get the extension re-enabled there; top level WMF people see this as a very high priority. [16:20:04] wb hexmode [16:20:18] siebrand: yes, we can do that, eventhough not a good idea. We also need to see how much change it will required to do that [16:20:22] computer froze... :P [16:20:51] santhosh: if that is what it takes, it is what it takes... [16:21:32] oh, in case you missed it when I pointed to it earlier, here is MS employee being interviewed on l10n: http://www.youtube.com/watch?v=emiHr4t_SyE [16:21:39] by a puppet! [16:21:40] Browser stats for July (http://www.w3schools.com/browsers/browsers_stats.asp) indicate this issue hits 30% of users. That is a lot. [16:22:12] (or is it chrome, safari and opera? -> 35%+) [16:22:17] I think there is one bug in etherpad we didn't go over yet [16:22:24] Nikerabbit: oh. Which? [16:22:45] https://bugzilla.wikimedia.org/29671 Use user-language names of Special pages in the URL [16:22:51] does everyone think it is a wontfix? [16:22:56] +1 [16:23:10] SPQRobin doesn't think so (yet) btw. [16:23:22] I agree with WONTFIX [16:23:28] ah, ok. [16:23:28] it was just an idea [16:24:07] ok, so are we done, hexmode? [16:24:08] alright. Are we done then? [16:24:17] I think so [16:24:17] santhosh: yep [16:24:35] thankyouverymuch [16:24:36] by the way, FYI, I sent an email to wikitech about including a list of ISO 639 language codes/names in MediaWiki [16:24:44] could be interesting [16:25:25] hexmode, aharoni, Nikerabbit, santhosh, sumanah, SPQRobin, AryehGregor, Krinkle: thank you! [16:25:49] SPQRobin: which ISO 639?;) [16:26:03] ISO 639-1/2/3 [16:26:14] hmm. That's 7k codes. [16:26:28] I'd like to support 7k languages [16:26:38] yes, but there are several use cases where we want that list [16:26:40] siebrand, you're welcome. are you here for a few minutes? i have a q about bug 30611. [16:26:44] thank you all [16:26:55] aharoni: shoot. Looking. [16:26:59] !bug 30611 [16:26:59] --elephant-- https://bugzilla.wikimedia.org/show_bug.cgi?id=30611 [16:27:21] hexmode: do you need any help to finalize the etherpad? [16:27:22] ? [16:27:31] Zack mentions in the last comment the dotted circle and gives Hebrew as an example. [16:27:34] siebrand: lemme check [16:27:35] aharoni: ah, the patch I applied. [16:27:50] aharoni: yes, I read that, but didn't understand. [16:27:52] yes, that patch, and Zack's further comment. [16:27:58] you don't really have to :) [16:28:10] good! [16:28:21] anyway, he gives Hebrew as an example. i looked at the code for Hebrew and actually it's wrong. [16:28:39] The current code for Hebrew says [ "\u05b0\u25cc", "\u05b0" ], where \u05b0 is a vowel diacritic ("niqqud") and \u25cc is the dotted circle. [16:28:46] *hexmode takes down the twn site notice [16:28:56] siebrand: I think I' [16:29:15] siebrand, the file is http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/WikiEditor/modules/jquery.wikiEditor.toolbar.config.js?view=markup [16:29:15] ve got the etherpad... now to get the report done [16:29:19] hexmode: maybe an IRC triage for fixme bugs could be useful? My fixme bugs are still marked fixme because I would like to have input from other people. [16:30:02] SPQRobin: sure.... but it won't be for a couple of weeks: http://www.mediawiki.org/wiki/Bug_management/Triage [16:30:02] so it should be [ "\u25cc\u05b0", "\u05b0" ] instead [16:30:08] that was pretty cute (the puppet interview) [16:30:22] apergos: glad you liked it [16:30:33]