Features/Jetpack/Add-on SDK Localization API and Service

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

The ability for localizers to localize addons is key for addons to reach Mozilla's global userbase.

Addon localization in the traditional platform is cumbersome, because addon developers must solicit localizations themselves and manually integrate them into their addon packages.

Addon localization in the SDK comprises a simple, high-level API for specifying the strings to localize, a localization service to which addons distributed by AMO are automatically submitted for localization, a web application through which localizers can localize addons, and automatic repackaging of AMO-distributed addons with new and updated localizations.

2. Users & use cases

The target audience is addon developers. The use case is an add-on developer using the Add-on SDK (either directly or via the Add-on Builder) to build an addon.

3. Dependencies

The feature depends on work to be done in the SDK, AMO, and a localization service with which AMO interacts to solicit and retrieve localizations.

4. Requirements

The feature must enable localization of addons and distribution of localized addons without requiring the developer of an addon to do anything other than identify the strings needing localization and submit the addon to AMO.

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

A good deal of work to implement this has already been done by Gandalf - what is missing is the coordination among Jetpack, Gandalf, and AMO as was originally planned. In addition, AMO's time to work on this is very limited and perhaps too far away for us to effectively launch this feature in a timely manner. To that end, we may want to move the "pushing to the 3rd party service" side of this to the Add-on Builder.

In addition, since most of the hard work has been done, we can launch this in phases:

Phase 1: The initial step is simply to land gandalf's "Common Pool" module. This will allow devs to flag strings to translate with a _("string to translate") - When done, the dev can then upload the xpi to https://l10n.mozillalabs.com/projects/p/mozilla-jetpacks/upload/ and the strings will enter the common pool to be translated, and returned to the developer.

Phase 2: In this stage we should iterate on the l10n support, including taking a look at localizing html files (a method for hosted html as well as included html).

At the same time, we should look at adding automatic uploads to transifex directly from the Online Builder so that devs don't have to worry about doing that themselves.

Phase 3: when the AMO devs have time to implement it, we should have the automatic uploads work directly from AMO when a dev uploads his/her xpi to AMO.

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes

Existing work:

• http://diary.braniecki.net/2011/01/12/jetpack-localization-common-pool-approach/
• http://diary.braniecki.net/2011/01/12/using-common-pool-tutorial/