Ubuletteappstartup.xpt too00:02
Ubuletteand i've missed a few others too :P00:02
carlosasac: hi10:36
asaccarlos: ok, for the import the idea is to produce a debian/xpi/en-US.xpi ... i think that should be ok?10:37
carlosyeah, it would be in any directory you want10:37
asacok great. then the import is pretty much clear i guess10:37
asaccarlos: now for the export we wonder how easy its possible to pipe meta information through10:38
carlosasac: could we defer this, I have a meeting with other Translations team members10:38
asacis that possible? e.g. like adding more meta info to the .po files10:38
asacor reexporting some txt files we gave you ? (either in .xpi or somewhere else)10:39
asaccarlos: sure10:39
carlosok, thanks10:39
asaccarlos: when do you expect?10:39
asac(so i can plan what to do in the next time ;))10:39
asacs/next /mean/10:40
carlosnot more than 30-45 minutes (I hope no more 30)10:41
carlosI'm almost ready...11:22
asacyeah :)11:22
asaci am still thinking, so no need to hurry ;)11:22
carlosok, ready11:26
carlosasac: which kind of metadata do you need to export?11:26
asaccarlos: ok ... the two pastes above show the additional info we need to make .po -> .xpi happen11:26
carlosasac: 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 deployed11:27
asacyes. but we can work on demo to test?11:27
asaccarlos: look at the pastes11:27
asacthe first will be maintained in langpack-o-matic11:27
asacfor now we can also put the other template in there, but in the  long run it would be better to pipe that file through11:28
asacso its not a blocker ... just a nice to have :)11:28
carlosbut is it an static file content?11:29
carlosor are we supposed to update any part of it depending on the exported file?11:29
asacwhat do you mean by static?11:29
asacno launchpad doesn't need to update that11:29
carlosthat I should give you it without modifications11:29
asacjust export alongside with the .po11:29
asacthe langpack-o-matic would use that to create the .xpi11:29
carlosthen, why cannot be included in langpack-o-matic?11:29
carlosjust wondering11:30
asacbecause its something you can better generate during build11:30
asackeeping that up to date manually is a pain11:30
carloshmm, so I need to add also a way to edit it from Launchpad?11:30
asacwell ... at least it would be error prone and you always have to think about fixing langpack-o-matic if xpi changes somehow11:30
asaccarlos: i would like to produce it during the build ... and get it back unmodified from launchpad next to the .po files in the tarball11:31
asac(not really next like in directory, just somewhere in the same tarball)11:31
carlosoh! I see11:32
carlosso I get it from the imported tarball11:32
carlosand you want it back when I do the export11:32
carlosthat makes much more sense11:32
asacyes could put debian/xpi/en-US.xpi + debian/xpi/xpi-meta.xml  into that tarball11:33
carloswe don't have a way to do it right now, but an easy workaround would be to include it inside the en-US.xpi file11:33
asacand 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.xml11:33
carlosgiven 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
asaccarlos: oh ... so we get the en-US.xpi out?11:34
asacthat would be good enough11:34
carlosno, but we could11:34
asacyes, that would be perfect than11:34
carlosI already have that information11:34
asacshould allow us to do whatever we want ;)11:34
carlosso is just a matter of changing the language pack script to export the en-US.xpi + all .po files with translations11:34
asacyes. great11:35
asaccarlos: just so we understand: there would be lots of en-US.xpi in the tarball right?11:35
carlosasac: should I assume that en-US.xpi already provides that xml file you wanted?11:35
asace.g. ubufox/en-US.xpi + firefox/en-US.xpi and so on?11:35
carlosbut you are free to choose the layout you want for them11:36
carloseven its file name11:36
asaccarlos: yes. if you just export the en-US.xpi unmodified i will take care for the rest11:36
asacthe good is that its easily extensible without changing launchpad anymore11:36
asac(most likely i should not use .dtd or .properties :))11:36
carlosright, the only change I need to do is to export the .xpi file as part of the language pack export11:37
asaccarlos: ok i have another tiny action/bug fix for the export/import ?11:37
asacthere is: #: en-US.xpi/chrome/ubufox.jar/locale/en-US/ubufox.dtd(ubufox.launchpad.reportbug.label)11:37
asaccould we make that:11:37
asac#: en-US.xpi/chrome/ubufox.jar/locale/en-US/ubufox.dtd(ubufox.launchpad.reportbug.label)11:37
asacfor cases where the dtd is in a jar?11:37
carlosyes, you can even ask us for any other information you want there, but that change is trivial11:38
carlosso count with it11:38
asaccarlos: ok, do you consider non-jarrred translation files?11:38
asace.g. if in .xpi there is just a directory locale/en-US/something.dtd ?11:38
carlosyes, it should work by default11:38
asacok ... i will handcraft a .xpi for that case so we can test. if we support both we support everything. sounds good!11:39
asaccarlos: ok, how do we document any ACTIONs found?11:41
asaclike, export en-US.xpi ?11:41
asaci think we have three ACTIONS on your side:11:43
asac 1. MANDATORY for hardy: fix comment to include '!' in .po file11:43
carlosI will file a bug about it and target it for our current cycle11:44
asac 2. MANDATORY for hardy: fill the untranslated msgstr .po files with en-US translations11:44
asac3. OPTIONAL for hardy: export .xpi11:44
asacdoes that sound reasonable?11:44
carlosfill the untranslated msgstr .po files with en-US translations?11:44
asacyes https://pastebin.canonical.com/2860/11:44
carlosdoes it mean that if we leave the string empty, firefox will fail?11:45
asaccarlos: in most cases it will auto fallback, but there are other cases where this doesn't work11:45
asacso to be safe punching original text in is the right way to go for now11:45
asacis that hard?11:45
carlosthen, what I'm going to do is to export it but setting the 'fuzzy' flag which means the translation is not valid11:46
carlosso we don't end in a situation where we get English strings as Spanish translations if someone imports again the .po file into Launchpad11:46
asacreimport .po file?11:46
asacwhy would that happen?11:47
carlosI wonder... in current .xpi packages, does it mean that if something is not translated right now, we will get an English string?11:47
asacwe import .xpi?11:47
carlosasac: yes, but translators using Launchpad will get the .po files, edit it outside Launchpad and import them back11:47
asacah ok11:47
asaccarlos: ok i have a better idea11:47
carlosso I need to be sure they don't break it at all11:47
asacyou just export the en-US.po file as well11:47
asacwe will look into that and do the magic in the script i guess11:48
carlosasac: I even have another idea ;-)11:48
asacthats better, right?11:48
asacgo ahead ;)11:48
carlosfix our export code and stop using the IDs as msgid11:48
carlosand use the English string11:48
carloswhich is what we were supposed to use11:48
asacwell. the ids are pretty handy atm11:48
carlosand use msgctx field to note the id in firefox11:48
carlosso you get something like:11:49
carlosmsgid 'Foo bar'11:49
asaci have another question: what happens if two .xpis provide the same msgid ?11:49
carlosmsgctxt "foo.bar"11:49
carlosmsgid "Foo bar"11:49
carlosmsgstr "Foo bar translation"11:49
asaci guess once the msgids are real english text there won't be a clash?11:49
asacotherwise we will get the same translation for every msgid, right?11:49
carlosright, msgid entries are unique11:50
carlosasac: is that a problem?11:50
asacok ... but would they still be exported twice?11:50
asace.g. ubufox.po + firefox.po use the same msgid ?11:50
carloswhat we do is to aggregate them (I need to check whether we do it right now)11:50
asacwould it be wiped from ubufox.po ?11:50
carlosoh, that11:50
asaci just want to know if its still listed in the .po files :)11:51
carlosno, one doesn't affect to the other11:51
carlosso yes11:51
carlosboth fr.po files will include the messages11:51
asacso once we use the english texts as msgids there won't be any problem at all11:51
carloseven different translations11:51
asacuntil then, there might be some loss of information if msgid clash11:51
asacbut that isn't a problem imo either11:51
carlosmy question was more in the sense whether the same id would be used inside the same xpi file at the same time11:51
asacoh really?11:51
asacno ... they are unique for each xpi11:52
carlosasac: yeah, ubufox and firefox will be independent contexts11:52
carlosasac: someone at FOSDEM said there are cases where is not true11:52
asacok ... but if ubufox didn't receive any special translation the firefox one would automatically be used?11:52
carloslike 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 differ11:53
carlosasac: I'm getting confused...11:53
asacno problem11:53
carlosis ubufox overriding firefox's strings?11:53
asaccarlos: no ... there might just be cases where there are entity id clashes11:53
carlosok, I just saw what you mean :-P11:53
asacthey should be rare though11:54
carloswe have suggestions in place for that11:54
carlosa translator will need to apply it, but we will show that firefox has it translated11:54
asaci justwondered if the windows translation would be used until someone does a special macosx translation for the same msgid :)11:54
carlosso he just needs to select it and save11:54
asaccarlos: ah ok11:54
asacnow i see11:54
asacso its a reviewed process11:54
asacsounds great ;)11:54
carlosasac: about per operating system id11:55
carlosyes, they said it's not common, but I guess it's possible11:55
carlosdo you know about any concrete case I could look at to see whether we could handle it?11:55
asacno :)11:55
carlosok ;-)11:55
asaci think i know what enough ;)11:55
carlosI guess our system will 'explode' when we find it11:55
carlosok, so for point 2.11:56
carlosinstead of exporting translations, the trick using msgctxt should be enough for you, right?11:56
carlosthat will give you the ID, en-US and translation strings all together in the same file and block11:57
asacyes. but its not mandatory as long as en_US.po is exported as well11:57
asac(though appreciated of course)11:57
asacwould ease things quite a bit11:57
carlosis the way to go so it's user friendly for translators wanting to use offline editors11:58
carlosand it should be also easy to implement11:58
asacyes. i just want to figure a roadmap that doesn't depend on lots of changes to launchpad :)11:58
carlosso count with that too11:58
carlosI could try to have everything done tomorrow. As I said, it's quite easy11:59
carlosit will not be available in production, though11:59
asacgreat ... can we push that to demo?11:59
carlosyeah, that's a good way to have it ready for testing now11:59
asacactually that isn't really a blocker either. i just would need a few sample export you could also do locally to get things started12:00
carlosasac: oh, also, there is a 4. point which is a must12:00
asacat least i don't need a full server to start with12:00
carlosasac: export en-US.xpi inside language pack exports12:00
asaccarlos: that was point 3 in my list ... wasn't it?12:00
asacthats not a blocker, but definitly a big nice to have12:00
carlosasac: yeah, I could provide you with a full firefox and ububox export using my laptop12:00
carlosasac: oh, by .xpi export I though about having the full process inside Launchpad ;-)12:01
asaccarlos: i think for now i would provide you with some special files that try hard to cover corner cases12:01
asacfor firefox i have to do some package adaption that might take a bit12:01
carlosnot just include the en-US.xpi file in the export12:01
carlosasac: ok, what you could do (if still possible to do for Hardy)12:02
asaccarlos: no ... i dont want to integrate that process for hardy12:02
carlosis to get all firefox language packs generated from language-pack-LL-base12:02
asaci will take care for the langpack-o-matic12:02
carlosasac: then, how are you going to deploy translations?12:03
asaci just need the en-US.xpi export and the .po files (with the fixes discussed above)12:03
asaccarlos: we will just include it in the langpacks12:03
carlosasac: so I don't really need to do the export in current language packs?12:03
carlosI'm confused :-)12:03
asacme too12:03
asacok: we get a tarball from launchpad with all translations12:03
carlosonly for firefox12:03
carlosor for all language packs?12:04
carlosgnome, kde, etc...12:04
asacno the one that we currently use :)12:04
carlos"no the one that we currently use :)", or "no, the one that we currently use :)" ?12:04
carlosjust to be 100% sure ;-)12:04
asacthe one you showed me yesterady (400+MB)12:04
asacthats all translations for the distro i guess12:04
asacin that tarball i would have .po files + the original en-US.xpi files if possible12:05
asacthen we fix langpack-o-matic source to produce all the translations and put them into the appropriate langpack .deb12:05
asacin hardy+1 we can reuse the script developed in langpack-o-matic to produce .xpis directly in launchpad12:06
asacthats my vision at least12:06
asacgot it?12:06
asaccarlos: just ask if there is anything not yet clear12:07
asaci want to be sure we have the same idea ;)12:08
carlosyeah, it's clear12:08
carlosphone, just a moment...12:08
carlosso you are going to kill firefox's sourcepackage with current language packs, right?12:13
asaccarlos: those are obsolete anyway12:13
asacwe currently have no translations for our default firefox12:13
carlosmy 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 month12:13
carlosasac: btw, talking about it... https://bugs.edge.launchpad.net/ubuntu/+bug/196504 ;-)12:14
ubotuLaunchpad bug 196504 in ubuntu "Firefox 3 Beta 3 appears untranslated in my Spanish desktop" [Undecided,New]12:14
asacwould it be possible to import .xpis now, so translators can already start?12:15
asaccarlos: yes, thats what i said. currently there are no translations.12:15
asacoh ... there is another tiny detail we have to figure on the import side12:16
asacso when things done you will get one en-US.xpi from xulrunner package and another from firefox12:16
carlosasac: yes, provide me with the en-US.xpi file and we could import it for Firefox, ububox, thunderbird and any other package in main12:16
carlosasac: we will have two templates in launchpad, 'firefox' and 'xulrunner'12:17
carlosand you will get two exports, with their own set of .po files12:17
asachowver, upstream doesn't have that split ... the the initial translations would come from one single de-DE.xpi for instance12:17
carlossomething like: xpi/firefox/firefox/en-US.xpi and xpi/firefox/xulrunner/en-US.xpi12:17
asacyes right12:18
asacthe export side is clear12:18
carlosasac: hmm...12:18
asaci wonder if it would work if upload de-DE.xpi (the big firefox translation from upstream) twice?12:18
asaconce for xulrunner ... and another time from firefox12:18
carlosasac: yeah, that will work, we will set the messages not used as obsolete12:18
carlosbut that will be internally12:18
carlosit will waste some db space, but nothing too bad12:19
asacso 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
asacwill launchpad just drop that?12:19
asac(those additional msgids)12:19
carloswe will store them internally12:20
asacah ok12:20
asacbut they won't get exported?12:20
carlosin language packs, no12:20
asac(nor become editable?)12:20
carlosin regular .po files for the users, yes, but as an obsolete message12:20
carlosasac: right12:20
asacok. i think thats fine than12:20
asacwill the given translation be provided as "suggestions"?12:21
asac(no idea what i am talking about ;) ... haven't used the translations system at all yet)12:21
asacanyway, i think i have enough information. the rest will pop up as we do this i guess12:21
asaci think the line is clear12:21
carloshmm, I'm not sure, I think it will not, but anyway, it will come as a suggestion from the other template anyway12:21
carlosasac: do you want to do an initial upload right now?12:21
asaci will start to implement the .xpi production tomorrow i guess12:22
carloswe will need to do another upload to fix some metadata when point 1. is fixed, but nothing will be lost12:23
asacand will handcraft some corner cases that you can import + export locally12:23
asachmm ... do we need to fix the "!" bug first before we import anything?12:24
asacor can you fix the exported comments later on?12:24
carlosa second upload will fix it12:24
asacah right. that sounds good12:25
carlosgiven that we don't use that information inside Launchpad, is not a problem12:25
asaccarlos: and how about the msgid -> msgctx switch ... won't that be a migration pain if we start now?12:25
carlosthat's not going to happen on import stage, but export stage12:25
asacdo we have a concept fo rthat?12:25
asacok. makes sense them12:26
carlosso we map what we have in our database in a different way we map it right now12:26
carlosthe information is there already, is just the way we use it12:26
asacok cool. but you can do that locally so we can have some test exports before things get rolled to demo or production?12:26
asacthats perfect then12:26
carlosdo you need anything else from me?12:28
asaccarlos: not yet.13:12
BUGabundoin FF3 the AUTOComplete is NOT case sensitive!!13:40
BUGabundoso if you are trying to type a case sensitive URL, FF will use the one in memory....13:40
BUGabundois this bug reported?13:40
BUGabundoguys have a look at bug 19656413:47
ubotuLaunchpad bug 196564 in firefox-3.0 "FF3 autocomplete is NOT case sensitive" [Undecided,New] https://launchpad.net/bugs/19656413:47
asacBUGabundo: i think thats a feature14:10
asaci cannot reproduce that you cannot type demo.txt14:11
asacthere is another bug that will select a suggestion if your mouse hovers it. maybe thats what you are seeing14:12
=== asac_ is now known as asac
asac[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:03
[reed]checkin-needed keyword, please15:11
[reed]makes my life way easier15:11
asac[reed]: set fixed1.8.0.x when committing, right?15:24
[reed]and then change to verified1.8.0.<x> when verifying15:24
asacthats the idea ;)15:25
asacjust wasn't sure if its the committers obligation to set fixed keywords15:25
[reed]it is15:25
asacyes, makes sense :)15:25
reed__asac, well, you usually give the people a little while to commit stuff themselves15:55
reed__after approving15:55
asacso not add that keyword?15:57
asacthat would be pretty unefficient for this "catch-up" batch15:57
asacok i will stop that then15:58
asacbut honestly, except those that you committed after caillon approved ... nothing was committed15:59
reed__yeah, it usually takes an e-mail from dveditz to everybody with a patch15:59
reed__(back when dveditz ran the branch)15:59
reed__reminding people to land15:59
asaci think we don't want to bug people ... at best wait a week, then commit without a reminder16:00
asaci will ask caillon what he thinks tomorrow during call16:01
reed__asac, if the bug was fixed by bzbarsky16:15
reed__just go ahead and add checkin-needed16:15
reed__just fyi ;)16:16
asacok ... i am done for today16:16
asacthanks for the info though :)16:16
reed__he's working on his graduate thesis, so his time is short16:16
reed__and likes when I commit stuff for him16:17
asacyeah ;)16:17
asacwhy would anybody object if someone else checks in what was already checked in on other branches?16:18
asacespecially given how long ago some of these patches were developed ;)16:18
reed__because they want the cvs blame16:19
armin76there's no xulrunner dir now?16:20
* reed__ laughs at trev16:20
asacreed__: yeah he bumped the flag back16:22
reed__I'm commenting16:22
armin76hrm...what happened with the xulrunner dir? :P16:22
reed__then you can grant it again16:22
asaci already did ;)16:22
asacand commented. but go ahead.16:23
asacarmin76: which xulrunner dir?16:23
armin76there used to be a xulrunner dir when you checkout with MOZ_CO_PROJECT=xulrunner16:23
asaci updated my branch one or two days ago ... i still have that dir16:25
reed__still there for me...16:26
armin76i'll checkout again...16:26
asacprobably a good idea :)16:26
asacNote to myself: don't use mouse-wheel while focus is on blocking flag16:27
armin76okay, wtf16:28
armin76with browser still the same16:29
reed__are there any closed security bugs up for committing?16:29
asacreed__: if i add checkin-needed i will CC you16:29
asaci think i approved one still closed up ... but will wait for a few days now ;)16:30
reed__or nom me for sg :p16:30
asacmaybe at some point that makes sense :)16:30
armin76i think i got it16:33
armin76with browser it doesn't pull it16:33
asacyes, use MOZ_CO_PROJECT=browser,xulrunner if you want both16:33
armin76nod, sorry about that, i checkec out browser instead :)16:34
armin76dropdown menus won't work now18:02
armin76with trunk18:02
armin76Ubulette: saw that?18:02
armin76rming ~/.mozilla fixes it18:04
Ubulette<armin76> dropdown menus won't work now <= which ones ?22:45
Ubuletteasac, if intrepid ships tb3, which profile name will it use ? upstream (.tb) or debian (.m-tb) ?22:59
asacUbulette: intrepid?23:08
Ubuletteisn't that the name ?23:08
Ubuletteinterpid ibex or something like that23:08
asaci doubt that there already is an official name23:08
Ubulettejust to name a few23:10
asacsee how well informed i am ;)23:10
Ubuletteit's about a week old23:11
UbuletteFeb 20 23:14:55 <Ubulette>      so 8.10 will be called Intrepid Ibex.. hmm. intrepid will be too long to type. maybe ibex then.. or ii23:12
UbuletteFeb 20 23:15:13 <Ubulette>      ii sounds good in japanese :)23:12
asacthis went to ubuntu-devel23:12
asaci mean ... i read that ;)23:12
asacprobably ended up in spam ;)23:12
asaclooks like i pressed tab too fast ;)23:14
Ubuletteit even spammed planet for several days23:17
armin76Ubulette: all menus didn't work, fixed with removing .mozilla23:28
Ubulettemine are fine with cvs20080227t120623:28
armin76as said, fixed rm'ing .mozilla :P23:32
Ubulettei hope it wont happen to me, i dont want to rm my .mozilla :p23:33
asacyeah read that23:34
Ubuletteyep, i've paste it here at least twice but you may have missed that too ;)23:35

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!