[00:02] appstartup.xpt too [00:02] and i've missed a few others too :P [10:36] asac: hi [10:36] hi [10:37] carlos: ok, for the import the idea is to produce a debian/xpi/en-US.xpi ... i think that should be ok? [10:37] yeah, it would be in any directory you want [10:37] ok great. then the import is pretty much clear i guess [10:38] carlos: now for the export we wonder how easy its possible to pipe meta information through [10:38] asac: could we defer this, I have a meeting with other Translations team members [10:38] ? [10:38] is that possible? e.g. like adding more meta info to the .po files [10:39] or reexporting some txt files we gave you ? (either in .xpi or somewhere else) [10:39] carlos: sure [10:39] ok, thanks [10:39] carlos: when do you expect? [10:39] (so i can plan what to do in the next time ;)) [10:40] s/next /mean/ [10:41] not more than 30-45 minutes (I hope no more 30) [10:42] cool [11:18] http://paste.ubuntu.com/5086/ [11:21] http://paste.ubuntu.com/5087/ [11:22] I'm almost ready... [11:22] yeah :) [11:22] i am still thinking, so no need to hurry ;) [11:26] ok, ready [11:26] asac: which kind of metadata do you need to export? [11:26] carlos: ok ... the two pastes above show the additional info we need to make .po -> .xpi happen [11:27] asac: the only problem with any change in that field is that we need to change Launchpad and thus, wait until the end of March when it will be deployed [11:27] yes. but we can work on demo to test? [11:27] carlos: look at the pastes [11:27] the first will be maintained in langpack-o-matic [11:28] for now we can also put the other template in there, but in the long run it would be better to pipe that file through [11:28] so its not a blocker ... just a nice to have :) [11:29] but is it an static file content? [11:29] or are we supposed to update any part of it depending on the exported file? [11:29] what do you mean by static? [11:29] no launchpad doesn't need to update that [11:29] that I should give you it without modifications [11:29] just export alongside with the .po [11:29] the langpack-o-matic would use that to create the .xpi [11:29] then, why cannot be included in langpack-o-matic? [11:30] just wondering [11:30] because its something you can better generate during build [11:30] keeping that up to date manually is a pain [11:30] hmm, so I need to add also a way to edit it from Launchpad? [11:30] well ... at least it would be error prone and you always have to think about fixing langpack-o-matic if xpi changes somehow [11:31] carlos: i would like to produce it during the build ... and get it back unmodified from launchpad next to the .po files in the tarball [11:31] (not really next like in directory, just somewhere in the same tarball) [11:32] oh! I see [11:32] so I get it from the imported tarball [11:32] and you want it back when I do the export [11:32] that makes much more sense [11:33] yes could put debian/xpi/en-US.xpi + debian/xpi/xpi-meta.xml into that tarball [11:33] exactly [11:33] we don't have a way to do it right now, but an easy workaround would be to include it inside the en-US.xpi file [11:33] and then i assume i get something in the translations tarball /usr/share/lang/en_US/ubufox.po ... and if possible we would also get /somedir/xpi-meta/ubufox.xml [11:34] given that you are going to generate it manually anyway... include that file inside allows us to not having to add a place to store such file (en-US.xpi file is already stored) [11:34] carlos: oh ... so we get the en-US.xpi out? [11:34] that would be good enough [11:34] no, but we could [11:34] yes, that would be perfect than [11:34] I already have that information [11:34] should allow us to do whatever we want ;) [11:34] so is just a matter of changing the language pack script to export the en-US.xpi + all .po files with translations [11:35] yes. great [11:35] carlos: just so we understand: there would be lots of en-US.xpi in the tarball right? [11:35] asac: should I assume that en-US.xpi already provides that xml file you wanted? [11:35] e.g. ubufox/en-US.xpi + firefox/en-US.xpi and so on? [11:35] right [11:36] but you are free to choose the layout you want for them [11:36] even its file name [11:36] carlos: yes. if you just export the en-US.xpi unmodified i will take care for the rest [11:36] the good is that its easily extensible without changing launchpad anymore [11:36] (most likely i should not use .dtd or .properties :)) [11:37] right, the only change I need to do is to export the .xpi file as part of the language pack export [11:37] carlos: ok i have another tiny action/bug fix for the export/import ? [11:37] https://pastebin.canonical.com/2860/ [11:37] there is: #: en-US.xpi/chrome/ubufox.jar/locale/en-US/ubufox.dtd(ubufox.launchpad.reportbug.label) [11:37] could we make that: [11:37] #: en-US.xpi/chrome/ubufox.jar/locale/en-US/ubufox.dtd(ubufox.launchpad.reportbug.label) [11:37] ouch [11:37] ;-) [11:37] en-US.xpi/chrome/ubufox.jar!/locale/en-US/ubufox.dtd(ubufox.launchpad.reportbug.label) [11:37] ? [11:37] for cases where the dtd is in a jar? [11:38] yes, you can even ask us for any other information you want there, but that change is trivial [11:38] so count with it [11:38] carlos: ok, do you consider non-jarrred translation files? [11:38] e.g. if in .xpi there is just a directory locale/en-US/something.dtd ? [11:38] yes, it should work by default [11:39] ok ... i will handcraft a .xpi for that case so we can test. if we support both we support everything. sounds good! [11:41] carlos: ok, how do we document any ACTIONs found? [11:41] like, export en-US.xpi ? [11:43] i think we have three ACTIONS on your side: [11:43] 1. MANDATORY for hardy: fix comment to include '!' in .po file [11:44] I will file a bug about it and target it for our current cycle [11:44] 2. MANDATORY for hardy: fill the untranslated msgstr .po files with en-US translations [11:44] 3. OPTIONAL for hardy: export .xpi [11:44] does that sound reasonable? [11:44] fill the untranslated msgstr .po files with en-US translations? [11:44] yes https://pastebin.canonical.com/2860/ [11:45] does it mean that if we leave the string empty, firefox will fail? [11:45] carlos: in most cases it will auto fallback, but there are other cases where this doesn't work [11:45] ok [11:45] so to be safe punching original text in is the right way to go for now [11:45] is that hard? [11:46] then, what I'm going to do is to export it but setting the 'fuzzy' flag which means the translation is not valid [11:46] so we don't end in a situation where we get English strings as Spanish translations if someone imports again the .po file into Launchpad [11:46] hmm [11:46] reimport .po file? [11:47] why would that happen? [11:47] I wonder... in current .xpi packages, does it mean that if something is not translated right now, we will get an English string? [11:47] we import .xpi? [11:47] asac: yes, but translators using Launchpad will get the .po files, edit it outside Launchpad and import them back [11:47] ah ok [11:47] carlos: ok i have a better idea [11:47] so I need to be sure they don't break it at all [11:47] you just export the en-US.po file as well [11:48] we will look into that and do the magic in the script i guess [11:48] asac: I even have another idea ;-) [11:48] thats better, right? [11:48] go ahead ;) [11:48] fix our export code and stop using the IDs as msgid [11:48] and use the English string [11:48] hmm [11:48] which is what we were supposed to use [11:48] well. the ids are pretty handy atm [11:48] and use msgctx field to note the id in firefox [11:49] ok [11:49] so you get something like: [11:49] msgid 'Foo bar' [11:49] sorry [11:49] i have another question: what happens if two .xpis provide the same msgid ? [11:49] msgctxt "foo.bar" [11:49] msgid "Foo bar" [11:49] msgstr "Foo bar translation" [11:49] i guess once the msgids are real english text there won't be a clash? [11:49] otherwise we will get the same translation for every msgid, right? [11:50] right, msgid entries are unique [11:50] asac: is that a problem? [11:50] ok ... but would they still be exported twice? [11:50] no [11:50] e.g. ubufox.po + firefox.po use the same msgid ? [11:50] what we do is to aggregate them (I need to check whether we do it right now) [11:50] would it be wiped from ubufox.po ? [11:50] oh, that [11:51] i just want to know if its still listed in the .po files :) [11:51] no, one doesn't affect to the other [11:51] so yes [11:51] great [11:51] both fr.po files will include the messages [11:51] so once we use the english texts as msgids there won't be any problem at all [11:51] even different translations [11:51] until then, there might be some loss of information if msgid clash [11:51] but that isn't a problem imo either [11:51] my question was more in the sense whether the same id would be used inside the same xpi file at the same time [11:51] oh really? [11:52] no ... they are unique for each xpi [11:52] asac: yeah, ubufox and firefox will be independent contexts [11:52] asac: someone at FOSDEM said there are cases where is not true [11:52] ok ... but if ubufox didn't receive any special translation the firefox one would automatically be used? [11:53] like a translation for MacosX and for Windows, there are cases where the ids are the same but depending on the operating system the translations may differ [11:53] asac: I'm getting confused... [11:53] no problem [11:53] is ubufox overriding firefox's strings? [11:53] carlos: no ... there might just be cases where there are entity id clashes [11:53] ok, I just saw what you mean :-P [11:54] they should be rare though [11:54] we have suggestions in place for that [11:54] a translator will need to apply it, but we will show that firefox has it translated [11:54] i justwondered if the windows translation would be used until someone does a special macosx translation for the same msgid :) [11:54] so he just needs to select it and save [11:54] carlos: ah ok [11:54] now i see [11:54] so its a reviewed process [11:54] find [11:54] fine [11:54] right [11:54] sounds great ;) [11:55] asac: about per operating system id [11:55] yes, they said it's not common, but I guess it's possible [11:55] do you know about any concrete case I could look at to see whether we could handle it? [11:55] no :) [11:55] ok ;-) [11:55] i think i know what enough ;) [11:55] I guess our system will 'explode' when we find it [11:55] :-) [11:55] hehe [11:56] ok, so for point 2. [11:56] instead of exporting translations, the trick using msgctxt should be enough for you, right? [11:57] that will give you the ID, en-US and translation strings all together in the same file and block [11:57] yes. but its not mandatory as long as en_US.po is exported as well [11:57] (though appreciated of course) [11:57] would ease things quite a bit [11:58] is the way to go so it's user friendly for translators wanting to use offline editors [11:58] and it should be also easy to implement [11:58] yes. i just want to figure a roadmap that doesn't depend on lots of changes to launchpad :) [11:58] so count with that too [11:59] I could try to have everything done tomorrow. As I said, it's quite easy [11:59] it will not be available in production, though [11:59] great ... can we push that to demo? [11:59] yeah, that's a good way to have it ready for testing now [12:00] actually that isn't really a blocker either. i just would need a few sample export you could also do locally to get things started [12:00] asac: oh, also, there is a 4. point which is a must [12:00] at least i don't need a full server to start with [12:00] ? [12:00] asac: export en-US.xpi inside language pack exports [12:00] carlos: that was point 3 in my list ... wasn't it? [12:00] thats not a blocker, but definitly a big nice to have [12:00] asac: yeah, I could provide you with a full firefox and ububox export using my laptop [12:01] asac: oh, by .xpi export I though about having the full process inside Launchpad ;-) [12:01] carlos: i think for now i would provide you with some special files that try hard to cover corner cases [12:01] for firefox i have to do some package adaption that might take a bit [12:01] not just include the en-US.xpi file in the export [12:02] asac: ok, what you could do (if still possible to do for Hardy) [12:02] carlos: no ... i dont want to integrate that process for hardy [12:02] is to get all firefox language packs generated from language-pack-LL-base [12:02] ok [12:02] i will take care for the langpack-o-matic [12:03] asac: then, how are you going to deploy translations? [12:03] i just need the en-US.xpi export and the .po files (with the fixes discussed above) [12:03] carlos: we will just include it in the langpacks [12:03] asac: so I don't really need to do the export in current language packs? [12:03] I'm confused :-) [12:03] me too [12:03] ok: we get a tarball from launchpad with all translations [12:03] only for firefox [12:04] or for all language packs? [12:04] gnome, kde, etc... [12:04] no the one that we currently use :) [12:04] "no the one that we currently use :)", or "no, the one that we currently use :)" ? [12:04] just to be 100% sure ;-) [12:04] the one you showed me yesterady (400+MB) [12:04] thats all translations for the distro i guess [12:05] in that tarball i would have .po files + the original en-US.xpi files if possible [12:05] ok [12:05] then we fix langpack-o-matic source to produce all the translations and put them into the appropriate langpack .deb [12:06] in hardy+1 we can reuse the script developed in langpack-o-matic to produce .xpis directly in launchpad [12:06] thats my vision at least [12:06] got it? [12:07] carlos: just ask if there is anything not yet clear [12:08] i want to be sure we have the same idea ;) [12:08] yeah, it's clear [12:08] phone, just a moment... [12:08] sure [12:12] back [12:13] so you are going to kill firefox's sourcepackage with current language packs, right? [12:13] carlos: those are obsolete anyway [12:13] we currently have no translations for our default firefox [12:13] my original question was whether you are going to release such language packs from the Hardy's global language packs right now, instead of wait for all this Launchpad integration that will be ready later next month [12:14] ok [12:14] asac: btw, talking about it... https://bugs.edge.launchpad.net/ubuntu/+bug/196504 ;-) [12:14] Launchpad bug 196504 in ubuntu "Firefox 3 Beta 3 appears untranslated in my Spanish desktop" [Undecided,New] [12:15] would it be possible to import .xpis now, so translators can already start? [12:15] carlos: yes, thats what i said. currently there are no translations. [12:16] oh ... there is another tiny detail we have to figure on the import side [12:16] so when things done you will get one en-US.xpi from xulrunner package and another from firefox [12:16] asac: yes, provide me with the en-US.xpi file and we could import it for Firefox, ububox, thunderbird and any other package in main [12:17] asac: we will have two templates in launchpad, 'firefox' and 'xulrunner' [12:17] and you will get two exports, with their own set of .po files [12:17] howver, upstream doesn't have that split ... the the initial translations would come from one single de-DE.xpi for instance [12:17] something like: xpi/firefox/firefox/en-US.xpi and xpi/firefox/xulrunner/en-US.xpi [12:18] yes right [12:18] the export side is clear [12:18] asac: hmm... [12:18] i wonder if it would work if upload de-DE.xpi (the big firefox translation from upstream) twice? [12:18] once for xulrunner ... and another time from firefox [12:18] asac: yeah, that will work, we will set the messages not used as obsolete [12:18] but that will be internally [12:18] ok [12:18] hmm [12:19] it will waste some db space, but nothing too bad [12:19] so what happens if you import a en-US.po ... and then you import a de-DE.po as a translation that has more msgids? [12:19] will launchpad just drop that? [12:19] (those additional msgids) [12:20] we will store them internally [12:20] ah ok [12:20] but they won't get exported? [12:20] in language packs, no [12:20] (nor become editable?) [12:20] in regular .po files for the users, yes, but as an obsolete message [12:20] asac: right [12:20] ok. i think thats fine than [12:21] will the given translation be provided as "suggestions"? [12:21] (no idea what i am talking about ;) ... haven't used the translations system at all yet) [12:21] anyway, i think i have enough information. the rest will pop up as we do this i guess [12:21] i think the line is clear [12:21] hmm, I'm not sure, I think it will not, but anyway, it will come as a suggestion from the other template anyway [12:21] asac: do you want to do an initial upload right now? [12:22] i will start to implement the .xpi production tomorrow i guess [12:23] we will need to do another upload to fix some metadata when point 1. is fixed, but nothing will be lost [12:23] and will handcraft some corner cases that you can import + export locally [12:23] ok [12:24] hmm ... do we need to fix the "!" bug first before we import anything? [12:24] or can you fix the exported comments later on? [12:24] a second upload will fix it [12:24] automatically [12:25] ah right. that sounds good [12:25] given that we don't use that information inside Launchpad, is not a problem [12:25] carlos: and how about the msgid -> msgctx switch ... won't that be a migration pain if we start now? [12:25] that's not going to happen on import stage, but export stage [12:25] do we have a concept fo rthat? [12:26] ok. makes sense them [12:26] then [12:26] ;) [12:26] so we map what we have in our database in a different way we map it right now [12:26] the information is there already, is just the way we use it [12:26] ok cool. but you can do that locally so we can have some test exports before things get rolled to demo or production? [12:26] yeah [12:26] thats perfect then [12:28] do you need anything else from me? [13:12] carlos: not yet. [13:13] ok [13:40] in FF3 the AUTOComplete is NOT case sensitive!! [13:40] so if you are trying to type a case sensitive URL, FF will use the one in memory.... [13:40] is this bug reported? [13:45] omgs! [13:47] guys have a look at bug 196564 [13:47] Launchpad bug 196564 in firefox-3.0 "FF3 autocomplete is NOT case sensitive" [Undecided,New] https://launchpad.net/bugs/196564 [14:10] BUGabundo: i think thats a feature [14:11] i cannot reproduce that you cannot type demo.txt [14:12] there is another bug that will select a suggestion if your mouse hovers it. maybe thats what you are seeing === asac_ is now known as asac [15:03] [reed]: there are a bunch of approvals for 1.8.0 branch ... do you need checkin-needed tag or do you see the approval1.8.0.15+ ones? [15:11] <[reed]> checkin-needed keyword, please [15:11] <[reed]> makes my life way easier [15:23] k [15:24] [reed]: set fixed1.8.0.x when committing, right? [15:24] <[reed]> yes [15:24] <[reed]> and then change to verified1.8.0. when verifying [15:25] right [15:25] thats the idea ;) [15:25] just wasn't sure if its the committers obligation to set fixed keywords [15:25] <[reed]> yep [15:25] <[reed]> it is [15:25] yes, makes sense :) [15:55] asac, well, you usually give the people a little while to commit stuff themselves [15:55] after approving [15:56] hmm [15:57] so not add that keyword? [15:57] that would be pretty unefficient for this "catch-up" batch [15:58] ok i will stop that then [15:59] yeah [15:59] so [15:59] but honestly, except those that you committed after caillon approved ... nothing was committed [15:59] yeah, it usually takes an e-mail from dveditz to everybody with a patch [15:59] (back when dveditz ran the branch) [15:59] reminding people to land [16:00] i think we don't want to bug people ... at best wait a week, then commit without a reminder [16:01] i will ask caillon what he thinks tomorrow during call [16:15] asac, if the bug was fixed by bzbarsky [16:15] just go ahead and add checkin-needed [16:16] just fyi ;) [16:16] ok ... i am done for today [16:16] thanks for the info though :) [16:16] he's working on his graduate thesis, so his time is short [16:17] and likes when I commit stuff for him [16:17] yeah ;) [16:18] why would anybody object if someone else checks in what was already checked in on other branches? [16:18] especially given how long ago some of these patches were developed ;) [16:19] because they want the cvs blame [16:20] uh... [16:20] there's no xulrunner dir now? [16:20] * reed__ laughs at trev [16:22] reed__: yeah he bumped the flag back [16:22] I'm commenting [16:22] hrm...what happened with the xulrunner dir? :P [16:22] then you can grant it again [16:22] i already did ;) [16:23] and commented. but go ahead. [16:23] armin76: which xulrunner dir? [16:23] there used to be a xulrunner dir when you checkout with MOZ_CO_PROJECT=xulrunner [16:25] i updated my branch one or two days ago ... i still have that dir [16:26] still there for me... [16:26] i'll checkout again... [16:26] probably a good idea :) [16:27] Note to myself: don't use mouse-wheel while focus is on blocking flag [16:28] hah [16:28] okay, wtf [16:29] with browser still the same [16:29] are there any closed security bugs up for committing? [16:29] reed__: if i add checkin-needed i will CC you [16:29] k [16:30] i think i approved one still closed up ... but will wait for a few days now ;) [16:30] or nom me for sg :p [16:30] maybe at some point that makes sense :) [16:30] hehe [16:33] oh... [16:33] i think i got it [16:33] with browser it doesn't pull it [16:33] yes, use MOZ_CO_PROJECT=browser,xulrunner if you want both [16:34] nod, sorry about that, i checkec out browser instead :) [18:02] meh [18:02] dropdown menus won't work now [18:02] with trunk [18:02] Ubulette: saw that? [18:03] oh [18:04] rming ~/.mozilla fixes it [22:44] hi [22:45] dropdown menus won't work now <= which ones ? [22:59] asac, if intrepid ships tb3, which profile name will it use ? upstream (.tb) or debian (.m-tb) ? [23:08] Ubulette: intrepid? [23:08] hardy+1 [23:08] isn't that the name ? [23:08] interpid ibex or something like that [23:08] i doubt that there already is an official name [23:09]