/srv/irclogs.ubuntu.com/2011/05/16/#ubuntu-mozillateam.txt

=== m_conley_away is now known as m_conley
=== m_conley is now known as m_conley_away
micahgchrisccoulson: FYI, you should be able to target to release anything you can upload now03:58
=== yofel_ is now known as yofel
SaammFirefox 5 beta is going to be released tomorrow. Can we download it from PPA?11:04
dpmchrisccoulson, 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:53
chrisccoulsondpm - with PO files12:54
chrisccoulson(i'm working on that bit now)12:54
dpmchrisccoulson, 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
chrisccoulsondpm - yeah, that's the intention12:56
chrisccoulsondpm - the mirror is here: https://code.edge.launchpad.net/~mozillateam/firefox-l10n/l10n-central12:57
dpmchrisccoulson, ok, gotcha.12:57
dpmchrisccoulson, 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 that13:00
chrisccoulsondpm - i'm trying to avoid any sort of conversion of xpi files :)13:01
dpm:)13:01
chrisccoulsoneverything will work purely on the source format13:01
chrisccoulsonand then the firefox build will produce xpi's based on this, which will be shipped unmodified13:01
chrisccoulsoni don't want us to be importing and hacking around with xpi's after they are built :)13:02
dpmchrisccoulson, 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/files13:02
dpmchrisccoulson, 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 archives13:03
dpmso it might save you some work there13:04
chrisccoulsondpm - that's good to know. thanks13:04
chrisccoulsoni was hoping that whatever work i do could go in to launchpad at some point anyway13:04
dpmthe only thing it needs is an en-US.xpi file and a dummy install.rdf file13:04
dpmyeah, that'd be awesome :)13:05
dpmchrisccoulson, 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:07
chrisccoulsoni would need to upload the converted data with the firefox source package to do that wouldn't i?13:08
dpmchrisccoulson, 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 upload13:09
chrisccoulsonyeah, we could probably do that. all of the data needed will be in the source tarball anyway13:10
dpmthen 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 branch13:11
=== m_conley_away is now known as m_conley
dpmchrisccoulson, 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)14:19
m_conleychrisccoulson: ping20:52
chrisccoulsonhi m_conley. how was your flight back?20:53
m_conleychrisccoulson: hey!  long, and uneventful.  I watched The Name of the Rose and Inspector Barnaby.  I was on a mystery-jones.  :)20:53
m_conleychrisccoulson: how about yours?20:54
chrisccoulsonyeah, 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:55
chrisccoulsoni wish they just let me sleep on the plane rather than having to get off, transfer and get back on again ;)20:56
m_conleyin a perfect world20:56
m_conley:)20:56
m_conleychrisccoulson: the reason I pinged - I was wondering if it'd be possible to get unitylauncher-extension into the PPAs?20:56
chrisccoulsonyeah, sure. i can do that tomorrow20:56
m_conleychrisccoulson: and have it install by default, similar to the globalmenu-extension20:56
m_conleychrisccoulson: cool, thanks. :)20:57
chrisccoulsonfor that, we'd probably need to put it in the archive for oneiric, which i can do too20:57
m_conleyplease do!20:57
chrisccoulsoni must upgrade to oneiric tomorrow :)20:59
chrisccoulsonthat will be fun20:59
m_conleychrisccoulson: let me know how it goes. :)21:03
OmegaDid we decide something on the accelerated release cycle?21:12
micahgOmega: WRT what?21:28
micahgchrisccoulson: let me know if you need something reviewed for archive inclusion21:29
=== m_conley is now known as m_conley_away
Omegamicahg: How we're going to handle it22:15
micahgOmega: handle what?22:17
OmegaWell, I mean what came out of the uds session.22:18
micahgOmega: there was no session22:19
micahgOmega: do you have a specific question?22:19

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