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

Please use "Edit with form" above to edit this page.

Status

Add-on SDK Localization API and Service
Stage	Planning
Status	In progress
Release target	TBD
Health	OK
Status note	Investigating as part of post-1.0 planning

{{#set:Feature name=Add-on SDK Localization API and Service

|Feature stage=Planning |Feature status=In progress |Feature version=TBD |Feature health=OK |Feature status note=Investigating as part of post-1.0 planning }}

Team

Product manager	David Mason
Directly Responsible Individual	David Mason/Myk Melez
Lead engineer	`
Security lead	`
Privacy lead	`
Localization lead	Zbigniew Braniecki
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

{{#set:Feature product manager=David Mason

|Feature feature manager=David Mason/Myk Melez |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=Zbigniew Braniecki |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

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: we can create a simple way for evelopers to push their xpi, on their own, to Transifex. This would allow us to have an l10n option for developers *now*.

Phase 2: Put the necessary "push to transifex" features into the online builder - perhaps we can connect this to the "push to AMO" functionality we already have.

Phase 3: When AMO can take on these tasks we can move the push functionality to the AMO side, utilizing the work that the Builder team has already done.

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

` {{#set:Feature open issues and risks=` |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. |Feature users and 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. |Feature 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. |Feature 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. |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature 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: we can create a simple way for evelopers to push their xpi, on their own, to Transifex. This would allow us to have an l10n option for developers *now*.

Phase 2: Put the necessary "push to transifex" features into the online builder - perhaps we can connect this to the "push to AMO" functionality we already have.

Phase 3: When AMO can take on these tasks we can move the push functionality to the AMO side, utilizing the work that the Builder team has already done. |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority	P1
Rank	999
Theme / Goal	`
Roadmap	Jetpack
Secondary roadmap	`
Feature list	Jetpack
Project	`
Engineering team	Jetpack

{{#set:Feature priority=P1

|Feature rank=999 |Feature theme=` |Feature roadmap=Jetpack |Feature secondary roadmap=` |Feature list=Jetpack |Feature project=` |Feature engineering team=Jetpack }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	`	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations 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/