Specification of Language Pack UI for Applications and Extensions
- 1 Requirements
- 2 Design Specification
- 2.1 User does not already have a version of the extension installed
- 2.2 User manually installs a locale pack for an extension that's already installed
- 2.3 A new locale pack is made available using extension update system
- 2.4 User installs an update to an extension which breaks the language pack
- 2.5 User installs multiple locale packs for a single extension
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
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:
- User does not already have a version of the extension installed
- User manually installs a locale pack for an extension that's already installed
- A new locale pack is made available using extension update system
- User installs an update to an extension which breaks the language pack
- 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.
User installs an update to an extension which breaks the language pack
Ideally extension updates will also feature updates to the language packs, but this may not happen simultaneously. If an extension update is found for an extension that has an installed language pack, the system should check to see if the language pack has also been updated. If it has, then the update should apply to both at the same time and the net effect for the user will be a localized update.
When the base extension update is available before the language pack update, the user should see the update as being available but that update should carry some indication that it is not localized.
User installs multiple locale packs for a single extension
Although there won't be a way to do this through the main UI, it's possible for a user to install multiple locale packs simply by expanding the XPIs into their profile/extension directory. The system should be smart enough in these cases to use the language pack that matches the browser's stated locale.
If the user wishes to switch between their language packs, they'll need to change their browser's stated locale using a tool such as Switch-Locales.