[00:01] it was one of the leaks [00:01] lets see [00:01] mozilla bug 405032 [00:01] Mozilla bug 405032 in Preferences "Changing feed handler to web handler leaks nsGlobalWindow" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=405032 [00:01] mozilla bug 388573 [00:01] Mozilla bug 388573 in General "ForecastFox 0.9.5.2 extension leaks 2 DOM Windows on Trunk but not on Branch" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=388573 [00:02] mozilla bug 388577 [00:02] Mozilla bug 388577 in General "FoxClocks 2.1.93 extension can leak nsGlobalWindows on trunk (but not on branch)" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=388577 [00:07] hmm mozilla bug 270159 still exists on trunk :( [00:07] Mozilla bug 270159 in Download Manager "Download manager adds extension regardless of file's own extension" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=270159 [00:13] hmm, cannot find it anymore. will look tomorrow [01:53] jetsaredim: ok mozgest dev landed license.txt [02:21] asac: how did you find that out? [02:22] i see it too [02:22] ok - i'll work on a package later tonight [04:50] asac: fyi - uploaded those mozgest code branches [05:23] wb [08:05] jetsaredim: thanks [08:05] the discussion went on and he apparently removed you from loop. finally he agreed to what we see now [08:08] * asac yawns [12:21] asac: I figured that [12:22] yeah. but in the end he agreed ... which is a success i guess [12:38] asac: with the UI/string freeze tomorrow, what's the plan with ubufox translations? bug #139380 would now have fi-FI, hu-HU and ru-RU translations. can you add those to the source tree, or have you heard something from the Launchpad folks? [12:38] Launchpad bug 139380 in ubufox "Untranslated strings in ubufox" [Undecided,Confirmed] https://launchpad.net/bugs/139380 [12:39] Mirv: yes, we will add them. we should also call for translations. [12:40] Mirv: https://code.edge.launchpad.net/~ex/ubufox/main thats the branch where i see ru-RU and fi-FI [12:48] asac: ok, great. the branch has old version of fi-FI translation, the bug's last comment has a newer version which also has the startup_homepage_*_url:s "translated" (I assumed that they're supposed to be translated to eg. index-fi_FI.html from ubuntu-artwork folders) [12:48] but it'll be good to have a post to ubuntu-translators list about the subject, so that translations are gotten and also people know what/how to translate [12:50] Mirv: doesn't the localized hompage work without tweaking hompage? [12:51] asac: not in the current version at least (/usr/share/ubuntu-artwork/home/index.html) [12:54] hmm [14:21] asac: hi [14:21] carlos: hi ... i need to get some food now :) [14:21] 30 minutes i guess? [14:22] sure === asac_ is now known as asac [14:52] carlos: now that we know that we won' get regular export for xpi i wonder if we can export something else? [14:53] carlos: we won't? [14:53] danilos: not for Hardy. [14:53] not for hardy [14:53] well, for Mozilla we are not importing anything yet [14:53] ah, right [14:53] asac: the only thing we could give you is .po files, is that useful for you? [14:54] sorry for jumping in the middle of conversation [14:54] thats why i am asking [14:54] we would need to setup the import, though [14:54] asac: that should be possible, and we could start exporting to XPI later when we have that working. [14:54] asac: I invited jtv and danilos to join us [14:54] if we could get .po files i would figure out if we could create the proper format somewhere else [14:54] hi all :) ... much appreciated [14:54] hi asac :) [14:54] asac: hi :) [14:55] ok ... so what can we import atm? [14:55] asac: translation-toolkit from pootle is supposed to produce .po files from xpi files and get them back from the .po files [14:55] hi asac [14:55] asac: but we were not able to get it running for Firefox [14:55] carlos: but they don't exactly work with any PO files [14:55] we use it for OO.org though [14:55] carlos: yes, i would look at that [14:55] danilos: I know, that's why I was trying to point that the whole process needs to be done with pootle [14:55] carlos, asac: I can look at the old code I have written for xpi exports, maybe we can reuse parts of that [14:56] asac: our .po files would not be compatible with translation-toolkit layout [14:56] danilos: to produce a script out of Launchpad? [14:56] thats ok. i just would like to take a look how they are assembled [14:56] carlos: well, to make a script to merge stuff from PO files and using en-US.xpi file [14:57] danilos: yeah, that was what I was thinking [14:57] getting that working might not be so much easier than getting exports working [14:57] ok so the idea is to import po files produced by pootle [14:57] right? [14:57] carlos: of course, that might include parts of LP code (like parsing en-US.xpi files) [14:57] (lets stick to the import side for now) [14:57] asac: also, we are waiting for a solution to validate .xpi files from Mozilla developers, that would help us to validate the output either from Launchpad or with some temporary script [14:57] jtv: not really, I had that working, only bits like install.rdf files and similar would have to be hacked around, and with non-LP code, we can hack around as we please [14:58] danilos: that's pretty cool [14:58] jtv: right, ugly hacks are faster, although is a hell to expand ;-) [14:58] but for this case, would work [14:58] jtv: and I had no regression tests either :) [14:59] carlos: jtv: i don't want any hacks. I would to figure what to do to make use of existing features in launchpad [14:59] danilos: some testing would be appreciated though, to prevent Firefox breakages [14:59] asac: well, using translation-toolkit is a hack too [14:59] s/any hacks/any hacks on LP side/ [14:59] ok [15:00] ok :) [15:00] asac: this would not be on LP side, it'd be on your side :) [15:00] asac: what danilo suggests is just provide a script to do such hacks outside Launchpad ;-) [15:00] so what import can you process as of now? [15:00] asac: gettext and xpi. [15:00] ok ... what happens if i throw an xpi at you? [15:00] asac: the template needs to be handled manually, but translations are handled already [15:00] asac: should work, though could do with some real-world testing. [15:01] asac: if I prepare a hand made .xpi to import en-US strings, users will be able to translate Firefox right now using Launchpad [15:01] carlos: ok. i could produce that during build i guess [15:01] asac: but, I'd prefer it if en-US.xpi was created along with the package build [15:01] what format do you expect? [15:01] asac: yeah, that would help [15:01] danilos: "me" [15:01] any special layout or can you parse any .xpi ? [15:01] danilos: ;-) [15:02] asac: we don't care about manifest files in our current implementation [15:02] carlos: why do you say "hand made" ? [15:02] asac: well, firefox doesn't provide en-US.xpi by default since 1.5.0.6 or something [15:02] so we have as a restriction that everything inside a .xpi files is for the same locale [15:02] (just to understand the current state: why couldn't we import an .xpi from the mozilla mirrors) [15:03] danilos: ok thanks. [15:03] carlos: ok thats good to know [15:03] asac: an xpi file with the en-US.jar file would be enough [15:03] carlos: no other meta information required? like install.rdf? [15:03] asac: afaik you could take a full one, delete some directories, and re-pack. [15:03] asac: the translations from mozilla mirrors are good for translations, but as long as I know, en-US.xpi doesn't exist at all [15:03] asac: not used right now [15:03] e.g. just en-US.jar in top level directory? [15:04] jtv: ok ... and import translations. would that work? [15:04] asac: hmm, having one is not harmful [15:04] although we don't use it at all right now [15:04] asac: it should, yes [15:04] do you look at any .jar inside the .xpi? or just those named en-US.jar ? [15:04] asac: any, iirc [15:05] asac: what danilos said [15:05] thats good. so you look for .properties files and .dtd ? [15:05] asac: yes [15:05] any .properties? [15:05] (most likely just those in a .jar) ? [15:06] asac: to provide us .xpi files, you will need to ask pitti to update his script that extracts translations to extract .xpi files too [15:06] carlos: can't we do this manually once to evaluate? [15:06] asac: any [15:06] asac: sure [15:06] and if we figure things out, do it automatically? [15:06] ok great. [15:06] for the testing phase, we could [15:06] and should, really [15:07] ok ... so what happens next? do you keep meta info about the key used by the xpi for each translation snippet? [15:07] asac: we get all .properties and .dtd files because we don't parse the .manifest file, but with this concrete case, it shouldn't be a problem [15:07] asac: yes [15:07] asac: we keep using those as message identifiers, but show the en-US "translations" in the UI [15:07] but i guess that meta info is not included in a .po exported, right? [15:08] ah good [15:08] that works already? [15:08] asac: yes [15:08] carlos: you'd have to export an en_US PO file, right? [15:09] jtv: we don't need to export en_US i guess, because we usually have that [15:09] otherwise, yes. [15:09] jtv: why would I like to do that? [15:09] ok, so could we throw just http://people.ubuntu.com/~asac/ubufox.xpi in? [15:10] carlos: phrased that badly... I mean, we also keep the symbolic msgids in the exported PO files, right? [15:10] asac: the problem with that, is that it doesn't use xpi files, if you produce fake ones per language, yes [15:10] jtv: yes, we do [15:10] carlos: ubufox.xpi is equiv to en-US.xpi [15:10] jtv: maybe, but that's very easy to break (that's what pootle/translate-toolkit do, which is why it's so fragile) [15:11] there are only en-US entitties in [15:11] asac: it contains translations [15:11] asac: really? [15:11] is that new? [15:11] yes. i didn't include any translation yet [15:11] last time I checked it had some translations [15:11] hmmm [15:11] lets see [15:11] if so, i can fix that [15:11] hmm [15:12] there is only locale/en-US [15:12] right, it doesn't include any translation... [15:12] how do you plan to deploy translations? [15:12] and contains one .dtd + one .properties [15:12] so a decent target to test [15:12] carlos: what do you mean? [15:12] how to package? [15:13] how to deploy translations [15:13] yes [15:13] I can investigate writing a script or two to actually construct xx.xpi's from a PO file exported from Launchpad and en-US.xpi (well, ubufox.xpi if needed :) [15:13] we could include them in language packs [15:13] danilos: that would be wonderful [15:13] not thought in detail about that. either one deb for each language or one deb for all (except en-US naturally) [15:13] asac: ok, so language pack is its place [15:13] no need to add new packages [15:13] no idea where it belongs :) [15:14] but most likely yes [15:14] asac: I do ;-) [15:14] carlos: that would make a lot of sense, but we need to know how would they be "activated" in firefox [15:14] at least that's the plan for firefox [15:14] danilos: there's a good one. Let's hope it's scriptable. [15:14] carlos: ok, then lets move on with the theory. ubufox.xpi has just a few entities, so i guess its a good try. can we do that? [15:14] danilos: install them as an extension in /usr/lib/firefox/extensions/ [15:15] carlos: danilos: new place is /usr/lib/firefox-addons/extensions/ [15:15] asac: sure [15:15] or /usr/lib/xulrunner-addons/extensions/ [15:15] asac: is that enough for firefox/anything else to register them [15:16] if it is, excellent [15:16] ? [15:16] (just completing danilos' sentence there) [15:16] jtv: :) [15:16] yes, if its a complete .xpi (unzipped) it will work [15:16] asac: I guess we should use IDs like: language-pack-LL-CC@ubufox.ubuntu.com or something like that for each language pack [15:16] but lets first work about getting an .xpi ... the rest will be easy imo [15:16] carlos: yes ... we can do all that [15:16] we can try it out on staging [15:17] ok, can we get an import round and than see what happens if you export en_US? [15:17] or do we need an initial translation? [15:17] jtv: that's going to be a problem, each import will require Tom around [15:17] jtv: what about using demo? [15:17] ok so Tom is the bottle-neck now? [15:17] ok figure out first ;) [15:17] carlos: does it run scripts and send email though? [15:18] asac: Tom is needed to simulate cron on staging. [15:18] jtv: not by default, that's why Tom is the bottle-neck [15:18] asac: we don't need any translation [15:19] asac: if you are able to provide me with an xpi for ubufox, we can try to get it imported today (Tom should be around right now) [15:19] carlos: take the one above ... or wouldn't it work? [15:19] carlos: code on demo is pretty old [15:19] the problem is with file exports and any other updates [15:20] http://people.ubuntu.com/~asac/ubufox.xpi [15:20] jtv: if no one is using it, we may get it updated [15:20] asac: let me try in my local computer.. [15:20] \o/ [15:20] carlos: this would certainly be worth requesting that [15:20] jtv: in worse case, we could use production [15:20] but hiding that template [15:22] carlos: okay, let's try on demo, and if anything breaks that we know is fixed already, ask for an upgrade. Failing that, we can look at production. [15:22] carlos: why hiding :) ... i need translations anyway ;) [15:22] asac: for testing [15:22] sure, just kidding [15:23] asac: well, I'm fine to leave it there... but would be confusing if we are not able to deploy it :-) [15:23] let's not get lost in this "what-if" case though. [15:23] ok ... all set? [15:24] import .xpi asap ...then try to export en_US [15:24] ? [15:24] (in the current default format) [15:24] asac: one thing: I think the name of the XPI file needs to be en-US.xpi [15:24] i assume i can export "per-package", right? [15:24] jtv: just rename to test then [15:24] jtv: I can do some 'magic' to avoid that [15:24] carlos: sounds exciting. [15:24] i don't thinks its a problem to get the name right before import if we do it automatically at some point [15:25] jtv: but only for testing [15:25] jtv: edit the path for the import queue entry :) [15:25] danilos: sssh, that kills the magic!! [15:25] carlos: ok, ok :) [15:25] :-D [15:26] Okay, now that Carlos' deep dark secrets have been revealed... [15:26] ok, how does the current export work? i ask launchpad: "export .po files for package XYZ"? [15:26] and then i get a tarball with all translations? [15:26] asac: you request an export in the normal way, and it'll ask you which format you want [15:26] asac: but PO and MO are the only options for now. [15:26] what is "the normal way" ? [15:27] asac: "Download translations" link. [15:27] actually, my real question is if launchpad remembers the entities needed for each package? [15:27] It's in the actions menu on the left. [15:28] so ... if i provide an en-US.xpi for xulrunner, i can get .po files for all the entities found in that .xpi? [15:28] (i think its too simple to be really a question:)) [15:29] carlos: it all comes out as one big PO file, right? [15:29] asac: it's a bit more complex (entities -> english strings -> PO files, and then you can basically get translations for all english strings which were linked to entities :)) [15:29] carlos: I mean, per XPI file per language. :) [15:29] one PO file per language? [15:29] asac: one PO file per template per language. [15:29] asac: IIRC an XPI file is treated as a single template. [15:29] asac: but that's essentially what I'm asking carlos. [15:30] asac: just a minute, I'm preparing an export for you... [15:30] ok lets assume i want to export entities for openoffice? [15:30] do i need to provide all entities i want to export or just the name "openoffice" ? [15:30] to get the translations for that package? [15:31] hmm, I found a missing feature with the .po export... [15:31] asac: https://pastebin.canonical.com/2858/ [15:31] that's current output, Launchpad UI shows the English strings, though [15:31] hmm paste.ubuntu.com? i currently have no pass for that [15:31] asac: look at #canonical channel [15:31] * asac looking [15:31] hmm, they removed it from the topic... [15:32] hmm its not there ... looking i wiki [15:32] asac: it's the same we use for our wikis [15:32] ok lets try ;) [15:33] yeah works [15:33] ok so it doesn't export the actual en-US texts? [15:33] carlos: the missing feature would be to add the English strings as comments? [15:33] would it work for translations? [15:33] asac: this is the Spanish translation, not the en-US "translation" that Carlos exported. [15:33] (as i am not interested in en-US exports atm) [15:33] he? [15:33] jtv: actually, to export the English string in the msgid [15:33] is there a spanish translation yet? [15:34] asac: no, but I requested its export, and given that there are no translations, it's a file without translations [15:34] let me show it with some translations... [15:34] carlos: makes sense [15:34] can you add one or two translations [15:34] ? [15:34] i could then start to code the .xpi producer for that ;) [15:34] looks rather straight forward [15:35] asac: https://pastebin.canonical.com/2860/ [15:35] that includes a translation [15:35] yeah [15:36] ok ... so what kind of script do you need? [15:36] lets start different: [15:36] how is the language-pack maintained? [15:36] is that something automatized? [15:36] carlos: should we have had this be exported with English messages as msgid's? [15:37] danilos: yeah, that's why I said I found something missing for the .po exports [15:37] danilos: but for what we want right now, it should be enough [15:37] danilos: inserting en-US msgstrs wouzld be safe, but i think we can try without them [15:37] carlos: right, ok [15:37] asac: of course [15:38] asac: what we do right now is to export the files to a tarball that Martin downloads and process automatically to produce the final .deb [15:38] ok ... this automated process is coded in a source package ? [15:38] so if i do apt-get source language-pack i can take a look? [15:38] what we would need is to add there all the scripts to produce an extracted .xpi that is installed at /usr/lib/firefox-addons/ [15:38] asac: langpack-o-matic, it's on LP [15:39] asac: I don't know all details, you will need Martin Pitt help [15:39] he does some preprocessing in our servers [15:39] carlos: actually he just documented it! [15:39] asac: I have some existing code I can share, though it might not be considered free software yet (I did make it while on company time and while working on LP :)) [15:39] ok if this turns out to be too difficult, we could most likely export all mozilla translation separately? [15:39] and the conversion from .po file into the native format should be done in that stage, given that it will depend on non free code coming from Launchpad [15:40] (e.g. i could do a mozilla-lang-pack source package if we otherwise need changes on launchpad side) [15:40] asac: sure, although at some point, it needs to be deployed in language packs, so better if we do it now [15:40] Pitti's docs for the language pack process: https://wiki.ubuntu.com/TranslationLifecycle [15:41] let me look [15:41] asac: not that I think of, Launchpad has all the import process working, is the export what is missing (and improve the imports, but basic functionality is there) [15:41] carlos: i mean: "export as .po files" [15:42] i can't believe that thats missing because you showed me an export ;) [15:42] :) [15:43] asac: .po export is not missing ;-) [15:43] I was talking about .xpi exports :-) [15:43] yeah ... so in worst case we could get a separate export of .po files for all mozilla packages? [15:43] asac: anyway, all this depends on Danilo being able to do that hack to produce the .xpi from the .po files [15:43] asac: yes [15:43] asac: that should work, and either separate or all together in a big tarball. [15:44] you can request them when you want to [15:44] carlos: he? you don't need to produce that hack. i can write a script for it [15:44] looks easy [15:44] asac: ok, if you think you can handle it, perfect ;-) [15:44] all information i need is: .po file + language + package [15:44] asac: ok, if you feel like doing it, be my guest, but I've already had working code for this :) [15:44] asac: your experience patching up the rdf etc. could be useful to us, in fact [15:45] danilos: can you ask your boss if you can free the code you currently have, so i can look at that [15:45] :) [15:45] jtv: boss, can I... :) [15:45] danilos: I already asked our boss [15:45] He's talking to his boss [15:45] asac: it's in process :) [15:45] wow ... i thought we had flat hierachies [15:46] asac: it's about the same depth as my gym in Bangkok, which has about a dozen staff. [15:46] asac: anyway, if you feel like it's simple, I guess going through administration is pita :) [15:46] i hate redoing things [15:46] asac: seriously though, can't make any guarantees that it will be approved, but I'll add this as a case in point. [15:47] who is your boss? [15:47] asac: Kiko. [15:47] ok [15:48] danilos: can you outline how you do it? [15:48] so i can see if i am thinking about a similar approach right now? [15:48] asac: sure [15:48] (though this is a pretty old code) [15:49] just a brief description (looking at https://pastebin.canonical.com/2860/) [15:49] asac: basically, recursively walk through a zip file and modify contents in-place as soon as I run into any messages needing translations (according to a PO file which is read at the same time) [15:50] ok there is a far simpler solutoin i guess (please think about it): [15:50] asac: anyway, you have a NDA signed with Canonical as a Canonical employee, so you should be able to see the code :-) [15:51] just add entities for to .dtd files and simple properties to .properties file [15:51] iterate through the .po file and do that for each msgid [15:51] the file to append this to can be parsed from the comment [15:51] done [15:52] asac: that could work, but I suggest doing this with an en-US.xpi file so you can actually modify existing files, and keep the English strings where there are no translations in the PO file [15:52] well ... i can implement that easily by looking at en_US.po file as a fall back [15:53] it looks easier for me to just append to files than replace (given that there might be entity ids somewhere in real texts) [15:53] maybe reuse the install.rdf from en-US.xpi though [15:53] asac: it needs some modifications AFAIK [15:53] yes reuse == copy + patch :) [15:54] maybe ffox will auto fall back to en-US on its own though. have to test that again [15:55] Sounds plausible. [16:00] asac: are you testing? [16:09] asac, hello ;) [16:12] jtv: not yet. got distracted [16:14] asac: so try uploading on demo, and letting us know so we can push it through. [16:14] me? [16:14] why would i upload anything? [16:15] (sorry ... i miss some context here. what is demo)? [16:15] and how can i access that [16:17] asac: I'm sorry, I thought you were planning to do that. [16:18] asac: demo is demo.launchpad.net [16:18] asac: for longer-running demo use of launchpad, without polluting production with test data. [16:18] ah right ... i am still in evaluation phase :) have to figure out langpack-o-matic [16:19] :) [16:19] so i know how to hook in [16:19] the import and export (well more or less) is clear for me atm [16:19] asac: then anything else you need? [16:22] not yet. on friday i will know more i guess [16:22] thanks! [16:23] asac: thank you. I'll quietly sidle away from the channel now. :-) [16:23] jtv: one more thing [16:23] asac: I knew it :) [16:23] in the .po file i don't see the lang code (e.g. spanish) [16:24] would the real code need to guess that from .po filename? [16:24] asac: right, it's really only in the file name. [16:24] ok ... how does the filename read? [16:24] $PROJECT-en_US.po ? [16:24] asac: there are several patterns. [16:25] what would we get? [16:25] asac: ideally (and if you'll be controlling the project, that can be reality) they'll have names like fr.po and en_GB.po [16:25] but they end up in a directory that reveals the project name? [16:25] Another pattern is $PROJECT-$LANGUAGE.po [16:26] asac: no, you're supposed to know the project when you request the export. [16:26] asac: that request is local to a product or distroseries/package [16:26] ok ... so langpack magic requests export for each individual project? [16:28] asac: there's a separate way to do it for the entire distroseries, but I'm assuming you don't need that here. [16:29] asac: if you do, well, we do generate them. [18:32] hi [18:34] hi [18:55] Ubulette: they applied the pyxpcom build patch. good. but we still see python startup issues, don't we? [18:55] yes [18:56]