On Thu, 2011-04-07 at 10:07 +0200, Martin Pitt wrote: > Priority: low > > Discuss integration of Firefox translations into Launchpad and > language-packs. This decayed quite a bit since Firefox 4.0 in Natty, > and right now we are back to just using the upstream tarballs. > > Martin
Hi, Thanks for bringing this one up. There doesn't seem to be any reason for me not to forward to this list the e-mail I've already sent to people internally about this, so I'll quote it all here: > Hi, > > So, for the last few days I have been thinking about the current state > of Firefox translations in Ubuntu, and thinking how we can improve it > in future releases (remembering that we are probably going to get 3-4 > major Firefox versions per year too). > > From my observations in Natty, here is a summary of where I think the > current issues are: > > 1) xpi updates are very much a manual process, and are decoupled from > Firefox version bumps (meaning that it is extra effort to update > xpi's). We need to be able to do this really really quickly in the > future. > > 2) po2xpi seems to be completely broken with the change to the chrome > format in Firefox 4. > > 3) po2xpi has produced broken xpi's in the past (e.g. bug 629640 is > because of a broken chrome.manifest). > > 4) For search plugins - Upstream Mozilla builds are shipping fully > translated search plugins for a lot of search engines. They are also > shipping per-locale search plugins which have a better relevance for > each group of users. The only localization we are doing for search > plugins is changing the search URL for Yahoo in some locales. The only > locale-specific plugin we are shipping is Baidu for zh-CN users. > > 5) Search plugin distribution seems completely broken to me. We're > having to maintain a copy of all of the en-US search plugins in > langpack-o-matic, for any locale where we make a locale-specific > change in just one plugin. The search plugins really don't belong in > langpack-o-matic. > > 6) The PO format that Launchpad exports to be parsed by po2xpi isn't > in a format which we can use to collaborate with upstream translators, > and it's not easily convertible in to the right format either (i.e. > properties and dtd files using the layout of the l10n-central > Mercurial repo's). > > I would like to resolve all of these issues, so I've been doing a bit > of pre-UDS thinking. > > - Firstly, I think we should kill po2xpi entirely. It's basically > doing what the Firefox build system is already very good at doing > (building xpi's from source). We should be using the Firefox build > system to build the language pack xpi's that we ship. This resolves > point 2 and 3. > > - This means that we will build the xpi's when we build Firefox, and > implies that we need to ship all locales with the Firefox source > package. I've had a look at the layout of the l10n-central repository, > and I think I've figured out how to merge all of the translations in > to a single Firefox source tree (although I haven't tried it yet). > This should fix point 1 (although it will make our source tarball > bigger) > > - This means that Firefox will output xpi's for every language in the > future (not just for en-US). We either need to package these in to > dedicated language packs for Firefox (e.g., firefox-locale-foo), or > Launchpad will need to import all xpi's and then make them available > to langpack-o-matic to build the language packs. In any case, the > xpi's built by Firefox will be in the final form that we intend to > distribute to users, and won't be modified by Launchpad or > langpack-o-matic. > > - I would still like to be able to use Launchpad to do Firefox > translations. However, with Firefox building its own xpi's we would > need to adopt a process similar to Chromium. I will write tools to > convert from source <-> po, which could be integrated in to Launchpad > eventually. This will enable us to import translations directly from > the Firefox source. It will also enable us to export translations from > Launchpad and easily convert them in to a format that could be merged > in to the upstream Mercurial repo. I will ask upstream if they think > this would benefit them (I don't see a reason why they wouldn't want > additional help doing translations). This fixes point 6. > > - If I merge the l10n-central branches in to our Firefox source, this > means that we will automatically get the upstream translated search > plugins (fixing point 4). I just need to be careful how we handle > plugins that we modify to change affiliate codes. This would mean that > we could drop the search plugins from langpack-o-matic (fixing point > 5). > > - Note that searchplugins are shipped independently of the xpi's. If > we are going to be shipping Firefox translations with our language > packs (as we do currently), this would mean Launchpad would need a > mechanism for importing and exporting the searchplugins alongside the > xpi's too. > > Anyway, these are only ideas at this stage. I'd be interested to hear > peoples thoughts and ideas too. > > Regards > Chris
signature.asc
Description: This is a digitally signed message part
-- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
