L10n/Apps

< L10n
Revision as of 11:37, 17 July 2014 by AxelHecht (talk | contribs)

DRAFT
The content of this page is a work in progress intended for review.

Please help improve the draft!

Ask questions or make suggestions in the discussion
or add your suggestions directly to this page.


This page and it's children are currently a dumping ground for Axel's thoughts.

Scope

The scope of Apps in these documents is WebApps that look like Gaia, not older than the latest stable branch.

We also limit our thinking to cost-free apps developed in the open. Thus we don't need to bother about access policies, vouchers for testers, etc whatnot.

Intent

Create an infrastructure that allows app developers to build and ship localized apps.

We're tossing around a few different concepts and proposals.

Scenarios

github PRs

Localizers fork the app's github repo, work on the translation in their own fork, and submit pull requests.

Tooling ecosystem
  • git
  • github
  • toolchain talking to github through APIs
Lock-ins
  • github
Existing tooling
  • None
Required tooling
  • TBD

Pootle

Developers publish their strings on a pootle instance, and export the localized strings into their app.

Tooling ecosystem
  • pootle
  • translate toolkit
  • no version control, no attribution in source code
Lock-ins
  • Pootle is the only editor
  • Pootle db is the only source of contribution metrics
Existing tooling
  • translate toolkit/pootle
  • conversion algorithms back and forth exist
Required tooling
  • TBD

Transifex

Developers publish their strings on transife, and export the localized strings into their app.

Tooling ecosystem
  • transifex
  • tx (transifex commandline client)
  • no version control, no attribution in source code
Lock-ins
  • transifex is the only editor
  • transifex db is the only source of contribution metrics
  • transifex is closed source, future development can be negotiated by anyone
Existing tooling
  • transifex, tx
Required tooling
  • TBD

The Gaia Way

For gaia, we have a repository per locale per branch that's holding the strings, including one for en-US.

Tooling ecosystem
  • hg repositories
  • loads of them
  • involved build process
  • extraction process for strings from gaia into gaia-l10n/en-US
Lock-ins
  • hg
    • for the string extraction code
    • for elmo
Existing tooling
  • elmo
Required tooling
  • set up and lead time are huge, don't scale
  • ending the life time of a project is undefined
  • most teams don't work on hg directly, but on a pootle instance
    • more setup
    • more tooling to move data back and forth
  • can benefit from Aisle

TBD

Tooling ecosystem
Lock-ins
Existing tooling
Required tooling