launchpad developmentContents |
Overview
Launchpad entry: https://blueprints.launchpad.net/rosetta/+spec/xpi-export-rdf
Created: 2008-12-17 by JeroenVermeulen
Contributors: AlexanderSack (pre-implementation call)
Depends on: n/a
Overall Summary
Summary: Exported XPI translation files must include an install.rdf file.
Goal/Deliverables: Generate an appropriate install.rdf file for every XPI file we export, based on the template's install.rdf but with certain customizations that the translation owners can configure.
We will know we have finished when we can produce the install.rdf that should go into any XPI export, so that the full XPI export feature can use it once completed; and the translation owners can configure the metadata specific to the particular translation being exported.
Release Note
XPI-based translations now let you configure some metadata that will go into the translation's install.rdf when you export them.
The metadata consists of a language-pack name (freely translatable), and a language-pack id. Be careful with the id: it should be unique, and not change unless absolutely necessary.
Rationale
The install.rdf file contains essential metadata for an XPI archive.
Use cases
Noi downloads a Khmer translation of Firefox in XPI format. Regardless of whether any Khmer translations were ever imported, the XPI contains an install.rdf with a unique language-pack id for Khmer, and a more appropriate name than "Language Pack - en-US, firefox."
Giovanni translates his Thunderbird extension to Italian. His template had an id of giovi-en-US, but his newly-started translation needs a unique id of its own. It is assigned a default id of giovi-it.
Sidonia starts to translate Ubuntu's Firefox package to Flemish. The id of the template from upstream is langpack-en-US@firefox.mozilla.org, but following the Ubuntu convention she can change this to langpack-nl_BE@firefox.ubuntu.com.
- Alexander refreshes the Ubuntu Firefox translations by uploading a fresh set of upstream XPIs. The ubuntu-specific language-pack ids remain as they were in the database.
Assumptions
- Users of XPI exports will test or check their language-pack ids before distributing their XPI files, so accidental id changes do not sneak into production. According to asac, Ubuntu users will test for this.
- Users with the privilege to change the translations will know not to change language pack ids gratuitously, and communicate well enough to set them appropriately.
- Metadata for an XPI export should come from the template and customization by the translation owners, not from translation uploads. (The latest translation upload may be out of date, or from an upstream language pack as opposed to a distribution one).
- Template ids and names will usually contain the string "en-US" (or maybe "en_US"), which we can replace with the code for the incumbent language.
- Language-pack names are freely localizable. Language-pack ids must be customizable but should stay stable.
User Interface
Translation supervisors must be able to configure the metadata, even if we can make good initial guesses.
Rather than add XPI-specific UI or database extensions, we treat install.rdf as a (partially) translatable resource inside the XPI archive, similar to the DTD and properties files it contains. The translation team or supervisor can edit the language-pack id and language-pack name as regular translatable strings.
The language pack id would have a msgid like "Description.id" and a context like "install.rdf." The name would be "Description.name" in the same context. The items will receive descriptive comments.
Implementation
Code Changes
The metadata messages are to be be generated when a POFile is created for an XPI-based translation. This may get a bit ugly because it's format-specific work that requires knowledge of the database schema.
For a DummyPOFile, it's best not to try and show the install.rdf messages. That does mean you have to start translating something else before you can set the name and id. On the other hand it doesn't create lots of empty translations or churn through our id space trying.
- Both name and id should be what they were in the template, but with the string "en-US" (or maybe "en_US") replaced by the language code. If there is no en-US/en_US in the original, append the language code instead.
When exporting, go through install.rdf as a special case: look up the file in the template (it should be in POTemplate.header) and substitute the configured id/name. If none have been defined, generate them on the fly based on what's in the template.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
how users will be pointed to the new way of doing things, if necessary. (If your change is big enough, consider using the rollout template.)
Unresolved issues
What's a good way to trigger the XPI-specific work when creating a POFile?
