||'''Contents'''<
><>|| == 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 [[ReleaseCycles/RollOutTemplate|rollout template]].) == Unresolved issues == * What's a good way to trigger the XPI-specific work when creating a {{{POFile}}}? ---- CategoryProposal CategoryTemplate