[03:58] <micahg> chrisccoulson: FYI, you should be able to target to release anything you can upload now
[11:04] <Saamm> Firefox 5 beta is going to be released tomorrow. Can we download it from PPA?
[12:53] <dpm> chrisccoulson, I'm trying to better understand how you want to import FF translations in the future. So you'd import them from the l10n repo into the FF upstream project in Launchpad. In which format, though? Would you feed Launchpad with xpi files or with PO files?
[12:54] <chrisccoulson> dpm - with PO files
[12:54] <chrisccoulson> (i'm working on that bit now)
[12:56] <dpm> chrisccoulson, ok, so on the import side, you'd have a mirror branch from the upstream l10n repo in LP, you'd then do the conversion from .dtd, .properties, etc and it would end up in another branch containing PO files that LP would be able to import?
[12:56] <chrisccoulson> dpm - yeah, that's the intention
[12:57] <chrisccoulson> dpm - the mirror is here: https://code.edge.launchpad.net/~mozillateam/firefox-l10n/l10n-central
[12:57] <dpm> chrisccoulson, ok, gotcha.
[13:00] <dpm> chrisccoulson, I was thinking, since LP already implements this on the imports side, would it not be easier to just mirror the upstream branch, add the en-US.xpi file (in case it's not already there) and let LP just import it like that? This way you'd save writing a tool for xpi -> po conversion, as LP already implements that
[13:01] <chrisccoulson> dpm - i'm trying to avoid any sort of conversion of xpi files :)
[13:01] <dpm> :)
[13:01] <chrisccoulson> everything will work purely on the source format
[13:01] <chrisccoulson> and then the firefox build will produce xpi's based on this, which will be shipped unmodified
[13:02] <chrisccoulson> i don't want us to be importing and hacking around with xpi's after they are built :)
[13:02] <dpm> chrisccoulson, yeah, sorry, I did not mean .xpi files, I was referring to the format. For example, LP can work with something like this: http://bazaar.launchpad.net/~dpm/translations-training/trunk/files
[13:03] <dpm> chrisccoulson, you know best the code and know the best implementation, I'm just suggesting this in case it helps, as LP can also work with source .properties and .dtd files instead of .xpi archives
[13:04] <dpm> so it might save you some work there
[13:04] <chrisccoulson> dpm - that's good to know. thanks
[13:04] <chrisccoulson> i was hoping that whatever work i do could go in to launchpad at some point anyway
[13:04] <dpm> the only thing it needs is an en-US.xpi file and a dummy install.rdf file
[13:05] <dpm> yeah, that'd be awesome :)
[13:07] <dpm> chrisccoulson, the only thing I'm not too convinced on is the fact that we'll be exposing translations in the upstream project in LP only, and not on the source packages.
[13:08] <chrisccoulson> i would need to upload the converted data with the firefox source package to do that wouldn't i?
[13:09] <dpm> chrisccoulson, yeah. So basically let the package do the same thing the branch will do: call the conversion tools. Or any other way in which you can feed the PO/POT file to LP in an upload
[13:10] <chrisccoulson> yeah, we could probably do that. all of the data needed will be in the source tarball anyway
[13:11] <dpm> then we could activate message sharing between the upstream trunk (or any other upstream series) and the corresponding Ubuntu source package, and disable the export in language packs. This would allow translators to translate from the usual place (on the source package), and their translations would be committed through message sharing and automatic exports to the linked upstream branch
[14:19] <dpm> chrisccoulson, I've left the feedback on the blueprint and a link to a possible approach to additionally allow translations of the source packages with the new method: http://people.canonical.com/%7Edpm/ff-oneiric/Firefox-O-Translations.png - please let me know what you think and especially if I depicted everything outside the orange square the way you were thinking (I'll update the diagram if there's anything wrong)
[20:52] <m_conley> chrisccoulson: ping
[20:53] <chrisccoulson> hi m_conley. how was your flight back?
[20:53] <m_conley> chrisccoulson: hey!  long, and uneventful.  I watched The Name of the Rose and Inspector Barnaby.  I was on a mystery-jones.  :)
[20:54] <m_conley> chrisccoulson: how about yours?
[20:55] <chrisccoulson> yeah, mine was quite uneventful too. although, when i transferred in zurich and got on my second flight, i realised that i was on exactly the same plane as my first flight (and with the same crew as well)
[20:56] <chrisccoulson> i wish they just let me sleep on the plane rather than having to get off, transfer and get back on again ;)
[20:56] <m_conley> in a perfect world
[20:56] <m_conley> :)
[20:56] <m_conley> chrisccoulson: the reason I pinged - I was wondering if it'd be possible to get unitylauncher-extension into the PPAs?
[20:56] <chrisccoulson> yeah, sure. i can do that tomorrow
[20:56] <m_conley> chrisccoulson: and have it install by default, similar to the globalmenu-extension
[20:57] <m_conley> chrisccoulson: cool, thanks. :)
[20:57] <chrisccoulson> for that, we'd probably need to put it in the archive for oneiric, which i can do too
[20:57] <m_conley> please do!
[20:59] <chrisccoulson> i must upgrade to oneiric tomorrow :)
[20:59] <chrisccoulson> that will be fun
[21:03] <m_conley> chrisccoulson: let me know how it goes. :)
[21:12] <Omega> Did we decide something on the accelerated release cycle?
[21:28] <micahg> Omega: WRT what?
[21:29] <micahg> chrisccoulson: let me know if you need something reviewed for archive inclusion
[22:15] <Omega> micahg: How we're going to handle it
[22:17] <micahg> Omega: handle what?
[22:18] <Omega> Well, I mean what came out of the uds session.
[22:19] <micahg> Omega: there was no session
[22:19] <micahg> Omega: do you have a specific question?