Extension Manager:Localized Addon Text

From MozillaWiki
Jump to navigation Jump to search

This requirement is essentially about placing localized information about add-ons into a fixed place for reading by the application and addons.mozilla.org alike.

Throughout this page I will use the term localizable information to refer to those parts of the add-on metadata that are/should be localizable, this includes name, description, creator, homepage, developers, contributors and translators.

Current Situation

Currently there are two places where add-on authors can place localizable information.

The first place is in the add-on's install.rdf file. The information here is used during install and by addons.mozilla.org. This information is only present in one locale.

The second place is in a localizable property e.g. extensions.<add-on id>.name. This can be used in the application after an extension is installed and is used in preference to the previous place since it is fully localizable.

New Requirements

The primary requirement here is that the localizable information must be available both in the application and to external users of the add-ons such as addons.mozilla.org. This means that the localizable information should appear in a defined place inside the add-on xpi, preferably in the install.rdf file and both AMO and the application already read their information from there.

Proposed Implementation

The proposed implementation adds the localizable information to the add-on's install manifest file.

Install Manifest Extension

It is proposed that a new property be added to the add-on's install manifest, em:localized. It will relate a set of localizable information to the add-on which can contain all the existing localizable information and in addition contains em:locale properties that mark which locales the information should be used for. The following is an example install manifest with most other properties removed for brevity:

<?xml version="1.0"?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:em="http://www.mozilla.org/2004/em-rdf#">
  <Description about="urn:mozilla:install-manifest">
    <em:id>TabSidebar@blueprintit.co.uk</em:id>
    <em:localized>
      <Description>
        <em:locale>de-DE</em:locale>
        <em:name>Tab Sidebar</em:name>
        <em:description>Zeigt in einer Sidebar Vorschaubilder der Inhalte aller offenen Tabs an.</em:description>
      </Description>
    </em:localized>
    <em:localized>
      <Description>
        <em:locale>es-ES</em:locale>
        <em:name>Tab Sidebar</em:name>
        <em:description>Muestra una vista previa de sus pestañas en su panel lateral.</em:description>
      </Description>
    </em:localized>
    <em:localized>
      <Description>
        <em:locale>nl-NL</em:locale>
        <em:name>Tab Sidebar</em:name>
        <em:description>Laat voorbeeldweergaven van uw tabbladen in de zijbalk zien.</em:description>
      </Description>
    </em:localized>
    <em:name>Tab Sidebar</em:name>
    <em:description>Displays previews of your tabs in your sidebar.</em:description>
  </Description>
</RDF>

Internal Details

Internally the em:localized properties are stored in the datasource as-is in the same way that em:targetApplication are currently. In order to speed up lookup of the appropriate property however additional properties are set on the extension:

PREFIX_ITEM_URI:TabSidebar@blueprintit.co.uk -> PREFIX_LOCALE:de-DE -> rdf:#$anon1
PREFIX_ITEM_URI:TabSidebar@blueprintit.co.uk -> PREFIX_LOCALE:es-ES -> rdf:#$anon2
PREFIX_ITEM_URI:TabSidebar@blueprintit.co.uk -> PREFIX_LOCALE:nl-NL -> rdf:#$anon3

Where PREFIX_LOCALE is urn:mozilla:locale.

Backwards Compatibility

In order to maintain backwards compatibility, where an em:localized doesn't exist for the required locale then the current method for retrieving the localizable information is used. So in the application's case a possible localized property is used and if not then the normal information on the install manifest. In the case of addons.mozilla.org the normal information on the install manifest is the only fallback.

It is suggested that add-on authors will want to continue using the localized properties in certain situations since that mechanism allows a third party locale pack to localize their add-on's metadata.

Discussion

It would be trivial to allow marking a em:localized property and valid for many locales just by including multiple em:locale properties on it.

Do we want to think about locale fallback, i.e. if a locale en is specified but the app is looking for en-US then do we get from en or just fallback to the default information as if the locale was missing completely.

In the case where a given set of localizable information doesn't include a certain property (description for instance) then do we just take the property as empty, or would it be more sensible to fallback to the default value for that property.

In certain situations (contributors, developers, translators) it might actually be a good idea to combine the localized information and the default information so the total set of contributors is taken from both the em:localized property and all the default em:contributor properties of the install manifest.

Related bugs