[Oneiric-Topic] Firefox translations in Launchpad/Language packs

[Chris Coulson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-desktop/attachments/20110407/9ffe71fe/attachment.pgp>