Specification of Language Pack UI for Applications and Extensions

Requirements

Applications and extensions should be able to have separate "locale packs" which are downloaded separately to add non-primary language support to the Application or Extension. The application or extension install.rdf and the AMO update service will provide the URIs of available language packs for applications and extensions. The UI should probably hook somehow on to the extension manager so that langpacks are automatically offered to non-English users, and so that additional langpacks are visually tied to the extension.

See bug 285848

Design Specification

The goal is to provide this functionality without any additional UI overhead in the extension manager. To do this, we propose that:

• when a language pack is installed, it does not appear on its own in the list of installed extensions, but rather adds a locale code to the name of the extension (ie: "My Extension 1.00" would become "Mon Extension 1.00 [FR]")

+-----------------------------------------+
| (  )  Mon Extension 1.00  (FR)          |
| (  )  C'est en francais!                |
+-----------------------------------------+

• when an extension is uninstalled, any associated language packs will also be uninstalled

We identified the following use cases that require additional design support for locale pack extensions:

1. User does not already have a version of the extension installed
2. User manually installs a locale pack for an extension that's already installed
3. A new locale pack is made available using extension update system
4. User installs an update to an extension which breaks the language pack
5. User installs multiple locale packs for a single extension

We plan to support use cases 1-4, but not to support use case 5 as we do not feel it is a common enough path to require first-class UI presence. For now we will point users with these requirements to extensions such as Switch-Locales.

User does not already have a version of the extension installed

The ideal support for this case would be that the system being used to publish the language pack will detect a user's declared locale and automatically offer the extension and language pack in a single XPI.

If the language pack is provided without the base extension, then the UI should prompt the user saying that a required extension is missing. If enough information exists to fetch and install the base extension, the UI should prompt the user to do so.

note: Unless the base extension is installed, the language pack should not be installed.

User manually installs a locale pack for an extension that's already installed

The locale pack should install like any other XPI, and once installed, the extension manager focus should be placed on the base extension which will now carry a localized name.

If the locale pack does not match the application locale then the user should be prompted to confirm that they want to switch the locale of that extension.

.----------------------------------------------.
| This software translates SomeExtension into  |
| %language. Do you want to continue?          |
|                                              |
|    [ Yes, Continue ]  [ No, Cancel ]         |
|                                              |
'----------------------------------------------'

If the user continues, then the locale pack should replace any existing installed locale pack.

A new locale pack is made available using extension update system

If an extension declares a locale-update value in its RDF file, when Firefox runs an extension update check it will also run a locale update check. If this check finds an update that matches the browser's locale (and has not already been installed) then it will appear as an update to the base extension. The user can choose to install it or not as they would any other extension update.