Extension Manager:Localized Addon Text: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
m (User:Mossop:Fx-Docs:LocalizedAddonText moved to Extension Manager:Localized Addon Text: Moving out of my user area to somewhere more sensible)
 
(3 intermediate revisions by 3 users not shown)
Line 9: Line 9:
The first place is in the add-on's install.rdf file. The information here is used during install and by [https://addons.mozilla.org addons.mozilla.org]. This information is only present in one locale.
The first place is in the add-on's install.rdf file. The information here is used during install and by [https://addons.mozilla.org addons.mozilla.org]. This information is only present in one locale.


The second place is in a localizable property e.g. <tt>extensions.<add-on id>.name</tt>. 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.
The second place is in a localizable property e.g. <tt>extensions.<add-on id>.name</tt>. 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, however these properties are only available when the add-on is installed and enabled.


== New Requirements ==
== 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 [https://addons.mozilla.org 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.
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 [https://addons.mozilla.org addons.mozilla.org].
 
A secondary requirement is that the localizable information must be available while the add-on is disabled.
 
This means that the localizable information should appear in a defined place inside the add-on xpi, preferably in the install.rdf file since both AMO and the application already read their information from there.


== Proposed Implementation ==
== Proposed Implementation ==
Line 21: Line 25:
=== Install Manifest Extension ===
=== Install Manifest Extension ===


It is proposed that a new property be added to the add-on's install manifest, <tt>em:localized</tt>. It will relate a set of localizable information to the add-on which can contain all the existing localizable information and in addition contains <tt>em:locale</tt> 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:
It is proposed that a new property be added to the add-on's install manifest, <tt>em:localized</tt>. It will relate a set of localizable information to the add-on which can contain all the existing localizable information and in addition contains at least one <tt>em:locale</tt> property that marks which locales the information should be used for. The following is an example install manifest with most other properties removed for brevity:


<pre>
<pre>
Line 57: Line 61:
</pre>
</pre>


=== Internal Details ===
Note that when an <tt>em:localized</tt> exists for the required locale then all other localizable information is ignored. That means that if the <tt>em:localized</tt> does not have a description property then the add-on is considered to not have a description, regardless of whether a description is specified directly on the install manifest.
 
Internally the <tt>em:localized</tt> properties are stored in the datasource as-is in the same way that <tt>em:targetApplication</tt> are currently. In order to speed up lookup of the appropriate property however additional properties are set on the extension:
 
<pre>
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
</pre>
 
Where <tt>PREFIX_LOCALE</tt> is <tt>urn:mozilla:locale</tt>.


=== Backwards Compatibility ===
=== Backwards Compatibility ===


In order to maintain backwards compatibility, where an <tt>em:localized</tt> doesn't exist for the required locale then the current method for retrieving the localizable information is used. So in the applications case a possible localized property is used and if not then the normal information on the install manifest. In the case of [https://addons.mozilla.org addons.mozilla.org] the normal information on the install manifest is the only fallback.
In order to maintain backwards compatibility, where an <tt>em:localized</tt> 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 [https://addons.mozilla.org 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.
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 <tt>em:localized</tt> property and valid for many locales just by including multiple <tt>em:locale</tt> 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 <tt>em:localized</tt> property and all the default <tt>em:contributor</tt> properties of the install manifest.


== Related bugs ==
== Related bugs ==


* {{Bug|257155}} - Bug tracking this requirement.
* {{Bug|257155}} - Bug tracking this requirement.

Latest revision as of 12:21, 25 February 2008

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, however these properties are only available when the add-on is installed and enabled.

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.

A secondary requirement is that the localizable information must be available while the add-on is disabled.

This means that the localizable information should appear in a defined place inside the add-on xpi, preferably in the install.rdf file since 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 at least one em:locale property that marks 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>

Note that when an em:localized exists for the required locale then all other localizable information is ignored. That means that if the em:localized does not have a description property then the add-on is considered to not have a description, regardless of whether a description is specified directly on the install manifest.

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.

Related bugs