L10n:B2G/Planning

Our roadmap and plan for scaling and shipping more locales in Firefox OS is provided below.

To successfully kick off and complete the full translation to 70+ languages will require a number of things in the initial set up and execution of the project

The information gathered here is based on information from the dashboards, language group research, and the l10n teams directory.

The good thing is that looking at dashboards we have infra set up for getting about 40 locales going A higher level summary of turning just translations into a fully shippable product is provided below.

We also need to figure out a better model or models for shipping all the localizations the get produced either though individual lang packs that can be added to any device, and/or a mechanism to ship all locales on devices, or at least a reference test device.

World Wide Availability of a Reference Device

The basic requirement is that we create a reference device(s) that work anywhere in the world, on any network, and offer the ability for Mozilla to define and ship any and all languages that are under development, testing, and ready to ship. We need to create anonymous (not under NDA) access to these reference devices, and be able to provide and control updates to the devices to provide the latest nightly and pre-beta builds.

This will allow us to enable localizers, and localization testing for all the possible markets that either we or partners want to pursue shipping devices in volume. Other open source developers that want to participate on the project will also benefit greatly from meeting this requirement and we will start to see the scaling of the project that we have seen on Firefox desktop.

By the end of 2014 we should plan for 5,000 users running nightly builds, and up to 150,000 user running weekly updated pre-beta builds. That would allow us a test audience similar to what we have on Firefox for Android. That's also a significant scaling up from where we are right now. Teams that have some type of testing devices are tracked here: https://docs.google.com/spreadsheet/ccc?key=0AqfkEC1pmwTidHN2djVXdVpIbU9jQWEyWm0zU05aOEE#gid=0

Specific Open Reference Device Requirements

we need a tracking bug for zeroing in on a open platform devices that will be supported anywhere in the world and we have some control over which languages get put on the device, and all build components.

https://etherpad.mozilla.org/fxosrefphone and e-mail threads

Lang Packs and Shipping all Locales on a reference device

to avoid performance and space constrains we need to lang packs that depend on background loading services features.

• we need a way to run the lang pack service in the background. Staś will email dev-b2g. ServiceWorkers might provide a solution. stas to follow up on getting l10n/l20n into those requirements and start a discussion that.

• L10n.js Refactor: bug 914414. This is the first step towards a fully async API which is required for langpacks. performance is goo. held up by memory use on contacts app. plan to land on 1.4, maybe backport to 1.3

• • Add formFactor() macro useful for tablets: bug 936532
  • Langpack proof-of-concept: http://informationisart.com/24/
  • Gandalf has been prototyping some UI ideas for language selection: http://labs.braniecki.net/i18n-ui/ ( https://github.com/zbraniecki/i18n-ui )

• navigator.languages: bug 889335. This is another requirement for langpacks: with varying coverage, falling back to the second-best localization is important for good UX
• Lang-packs are a long-term plan which shift control over locales available on the device from Mozilla to the users and the community. Mid-term, the next reference device is said to have enough disk space to fit all 80+ localizations. There might still be performance issues when doing so, so this sadly isn't the optimal solution, but definitely some progress.

Measuring and Monitoring the performance and footprint impact of adding all Locales

challenges: -diskspace - which devices will support which subsets of locales

-selection of which locales are at which states of development or commercial readiness. reference device may be capable of all 70, but other devices we will need to provide guidance on.

-performance degradation - If all locales are shipped on the reference device we need testing to ensure 70 available languages don't slow down the phone. current number (on 1.3) is about 10 milli-seconds per each additional locale on the first launch of any app. we will to figure out how to get better here.

-- gandi to provide data here.

We need to set up regular automation to get numbers on size and start up for 5, 10, 20, 40, and 80 locales. -- gandi

A public and reliable schedule that allows check points for localization work to proceed and catch up to development work

Where can this be found? Is https://wiki.mozilla.org/B2G/Roadmap the best "true source" for upcoming feature freeze and stabilization dates?

https://wiki.mozilla.org/Release_Management/B2G_Landing#Versions_and_Scheduling

As part of this and part of above we need better communication tools and process for really communicating which languages are ready for commercial distribution.

Internationalization Issues

there's a host of intl work around fonts etc. not sure if our per-version locale trackers work best in that model

some issues outlined here https://wiki.mozilla.org/L10n:B2G/Adding_Locales

RTL Specific issues are tracked as part of this dependency bug https://bugzilla.mozilla.org/showdependencytree.cgi?id=906270&hide_resolved=1

RTL Testing and Evaluation Enablers bug 900182, create fake locales.

Bug 934926 - [Gaia][l10n] replace partially translated locales in Gaia tree with upside down English for testing

CSS best practices for RTL?

RTL support

Background -

http://people.mozilla.org/~jbeatty/Articles/RTL.pdf 
also seeL10n:B2G/RTL

Tasks and action items:

• use the tracking bug to get organized: bug 906270
• implement pseudo-localization testing tools: bug 900182
• research existing guidelines for mobile design for RTL
  • CSS/HTML development guidelines
  • reach out to user research; understand who our target audience for RTL is and what interactions they are used to
  • engage UX to extract design guidelines
• schedule a testrun against the guidelines
  • check for things like, text over run, truncation, missing buttons
• find out what the Haida ( https://wiki.mozilla.org/FirefoxOS/Haida ) plan is
  • what important aspects of RTL need to be included in the Haida planning?
• do a test run with the localizer community on Android RTL; what they got right? what they didn't?
• get [ar] community more engaged, help them update the localization and dogfood
• develop a list of RTL reviewers/super-reviewers
  • who are the people who know about bidi? (smontagu) we need to understand what coding patterns get us into trouble. others?

Coding Best Practice

links to dev.gaia posts, wiki pages, and other references that help to understand how to write gaia code that is localizable

UX/UI Best Practices

Small Screens and Keyboards exacerbate problems around fitting in text that adequate explain user actions or help them to use the device. Early releases of FirefoxOS have been plagued by problems around cut off or overlapping text on screens or dialogs. We need to find a way and/or add tools to help reduce or minimize this problems.

Here are some ideas on string expansion http://www.kwintessential.co.uk/translation/articles/expansion-retraction.html

Here are tracking bugs with details on the e problems that have been encountered https://bugzilla.mozilla.org/show_bug.cgi?id=928174 1.2

spread the word on these four rules! (may need to work more on this)

• plan for 150% string expansion at a minimum when designing UX ---
• understand that some widely used strings in some widely used languages will degrade if less than 200% expansion is not provided.

Some simple and frequent examples where squeezing simple English action words is complicated in other languages.

• • 2 v. 6 == ok = V redu - Slovenian
  • 6 v. 20 == on / off = de encendido / apagado - spanish

more data that could inform UX design.

flod has a script that tells average expansion by lang.
extreme cases of max expansion.
expansion by small med. and large classes of strings.

some rules for plural forms https://bugzilla.mozilla.org/show_bug.cgi?id=929552

String re-use problems https://bugzilla.mozilla.org/show_bug.cgi?id=944749

not getting strings in the right locations to be picked up for localization https://bugzilla.mozilla.org/show_bug.cgi?id=941901

rules for changing white space?

more (helpful) localiziation comments?

standardization/naming conventions for buttons use - use verbs? nouns? capitalization?

get the reviewers trained up on l10n as the source of enforcement.

flod, axel and Delphine have more analysis coming.

willyranda posted to dev.gaia last week. https://groups.google.com/forum/#!topic/mozilla.dev.gaia/5OWAFgdUdcE

Average timeline for Localization cycle in FxOS

The entire localization cycle has been estimated to last approximately 8 weeks starting at String Freeze date. String Freeze is when no more features are landing, and no patches with string modification land (ie no more adding, modifying, taking out strings in patches). Thus, String freeze usually corresponds to Feature Complete (FC), the later being determined by Release Management. String Freeze should always appear clearly in all release schedules. Historically, Release Managers always announce it as fully part of the schedule and make regular reminders to make sure everyone remembers and respects this.

Translating work for most teams starts at string freeze, and localizers have then 2 weeks to catch up with their work before QA starts. 2 weeks after string freeze, QA starts doing Localization Runs on all available languages.

Typical calendar within FirefoxOS schedule

• Feature landing corresponds to our "soft string freeze": 80% strings have landed, even though we know some more will come. Developers and Release Managers must use the "late-l10n" keyword in Bugzilla if a patch with any kind of string modification is trying to land (ie an addition, an update or a deletion of a string). The late-l10n keyword should be used from this point onwards in the release. Release Management typically starts at this point being more aggressive towards if a feature/patch with a string change should land or not at this point in the cycle
• Feature complete is our "string freeze" date: no more strings land or change at that point in the cycle. It is ultimately up to release management if a patch is critical enough that it justifies breaking string freeze and thus can land. It is good to consult with l10n team about this, but we are not the ones who will decide in the end. Continue use of "late-l10n" keyword in this phase
• 2 weeks after string freeze: l10n Testing by QA starts. This is the date that we announce to localizers that they should have finished doing their chunk of l10n.

Then follows a cycle during which:

• 2 weeks: QA performs Localization Runs on all languages
• 2 weeks: localizers/devs fix bugs
• 2 weeks: QA/localizers verify that all issues are fixed

Concerning l10n testing for ONE locale, and assuming there are at least eight full-time testers on a locale, we have identified

• 3 days for one full localization run on one locale, bug filing, etc (full time)

Average number of bugs that turn up with this kind of testing

• For v1.3: 21 locales tested, 396 bugs identified in total. Mostly truncation issues: 265 total (https://bugzilla.mozilla.org/show_bug.cgi?id=967050)

Testing Calendar

• v1.3 Localization Run schedule: 21 locales tested
  • 1st half: Feb 3 - Feb 7
  • 2nd half: Feb 24 - March 4

• v1.4 Localization Run schedule
  • 1st half: April 14 - April 18
  • 2nd half: May 12-16

• v2.0 Localization Run schedule

See Testing Calendar

Scaling Locale Testing

Depends on the reference device item above

Tool set up and cooperation from tool providers

web translation frontends for l10n need set up for transafex and locomotion.

for Transifex we also need to set up a mozilla project that improves navigation to all Transifex work contributed to official mozilla projects

https://docs.google.com/spreadsheet/ccc?key=0Avegvj7k8t9ndG9ZWGlMWHpBYkZ5cEJjbzQ2eE1ZM0E&usp=sharing#gid=0

for locomotion we need expanded mentoring for existing firefox contributors to cover what is needed for FirefoxOS

need a better communication for requesting and tracking project setup on Transifex and Pootle when we add/change development and shipping branches on the Mozilla repository side.

need some guidance to localizers on which repositories to work on.

flod's working on master.

check with alex on when we get to a train model.

when is it ok, to start, and when to stop localization and on which repositories? and when do things stabilize?

part of this is getting greater clarity on what localizers are shipping.

talk to hal wine about how many repositories we can stand up and for how long they can realistically be support.

Community Health Connecting and communicating to teams about how to get involved

need to set up project kick off communication.

• info about development device.
• direction on where to contribute - which repos which tools.
• what larger issues are around keyboards and fonts and RTL and how to help there.

• we've got no docs on how to do firefoxos localization now. -gueroJeff has volunteered to write something up.

- simulator  (maybe not - does it work)
- phones?  getting them, what kind of phones are supported, what the plan is for reference device(s)
- where localization is happening - Pootle, Transifex
- repositories and branches
- how to produce builds and test
- how things work with partners
-- where phones get shipped, what gets put on the phones,  
    and how they come to getting tested and released.
      marketplace, masterfoxOS.

Language Groupings

Start of some research https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Aru_NzvpgGcgdGFBRUtYMEp5Wm82TGQtR0Nkb3VsbEE#gid=0

Marketplace

Where do we have support now?

• Currently supported [markets][1].

What are the need and challenge?

• Unless the product decouples language from market/regions, the promoted markets will be driven by the carriers.
• There are more languages supported on FFOS phone than there are markets promoted by carriers and supported by the product. Payment methods comply to only the countries promoted, and the rest falls into the Rest of the World category.
• Paid apps can vary per carrier even within the same market/country. The front end is controlled by Mozilla, but the actual payment flow is dictated by the carriers.

What do we do in market place and in product when marketplace is unavailable or does not make sense?

Legal Document

Not all documents are needed for a market launch, however, this is a good checklist of what can be localized. Legal decides what's relevant.

• Marketplace
  • Developer Agreement
  • Privacy Notice
  • Terms of Use
  • Preloaded Apps Terms
• FFOS: Privacy Notice
• Facebook: Privacy Information
• Firefox: Privacy Notice
• Firefox Cloud Services
  • Privacy Notice
  • Terms of Use
• Mozilla: Privacy Notice
• Website: Privacy Notice

Shipping locales

These locales are currently being shipped with Firefox OS and are in the shipping process infrastructure (Note: locales are additive from one version to another). Teams that have some type of testing devices are tracked here: https://docs.google.com/spreadsheet/ccc?key=0AqfkEC1pmwTidHN2djVXdVpIbU9jQWEyWm0zU05aOEE#gid=0

Locale	Language	LangGroup	Font	Keyboard	L10n tool	# of devices	Shipping
bg A	Bulgarian	Europe4	?	Cyrillic (30 letters)	?	3	1.2
bn-BD	Bengali	Asia3	Yes	Avro and Probhat Bangla	Pootle	5	1.3
ca A	Catalan	Europe1	?	QWERTY	Pootle (self-hosted)	2	1.1
cs A	Czech	Europe4	?	QWERTZ	?	4	1.1
de A	German	Europe3	?	QWERTZ	Transfix	3	1.1
el A	Greek	Europe1	Yes[2] [3] [4]	Greek (phonetically similar to QWERTY)	Transifex	1	1.1
es A	Spanish	LATAM	?	QWERTY	Transifex	5	1.0.1
hr A	Croatian	Europe2	?	QWERTZ	Pootle,	2	1.1
hu A	Hungarian	Europe4	?	QWERTZ	?	3	1.1
it A	Italian	Europe1	No	QWERTY	Mozilla Translator+ Transvision	5	1.1
mk	Macedonian	Europe2	?	Cyrillic	?	2	1.2
nl A	Dutch	Europe3	?	QWERTY	Transifex	2	1.1
pl A	Polish	Europe4	?	QWERTY	7	?	1.1
pt-BR A	Portuguese	LATAM	?	QWERTY	?	4	1.0.1
ro A	Romanian	Europe4	?	QWERTZ	?	?	1.1
ru A	Russian	Europe4	?	Cyrillic	?	4	1.1
sk A	Slovak	Europe4	?	QWERTZ	?	2	1.3
sr-Cyrl	Serbian (Cyrillic)	Europe2	?	Cyrillic (+sr letters)	?	?	1.1
sr-Latn A	Serbian (Latin)	Europe2	?	QWERTZ	?	2	1.1
tr A	Turkish	Asia3	?	QWERTY modified	Pootle	2	1.1
zh-CN A	Simplified Chinese	Asia1	?	QWERTY (PinYin, Chinese phonetic used for simplified Chinese)	?	1?	1.3
zh-TW A	Traditional Chinese	Asia1	?	BoPoMofo (or ZhuYin, Chinese phonetic used in traditional Chinese)	Narro	5?	1.3

NOTE: Though the keyboards for Latin-based and Cyrillic languages appear to be the same at high level, each language has special accented characters unique to that language. These characters can be shown by holding down a letter to show more options.

Locales Completed Firefox OS 2.0

These locales have complete translations in Firefox OS v2.0.

Partially completed locales

These locales have commenced localizing Firefox OS and have infrastructure in place to support building and shipping once their l10n is complete.

Locale	Language	LangGroup	Font	Keyboard	L10n tool	# of devices	Shipping

Promising locales

These locales have neither shipping infrastructure nor localization work complete, however, represent promising areas of exploration and require some investigation.

Locale	Language	LangGroup	Font	Keyboard	L10n tool	# of devices	Shipping target
af	Africaans	?	?	?	?	?	?
mr	Marathi	?	?	?	?	?	?
fa	Persian	?	?	?	?	?	?
nb-NO	?	?	?	?	?	?	?
sm	Samoan (Needs Repo)	?	?	?	Pootle	?	?
my	Burmese	?	?	?	?	?	?
zu	Zulu	?	?	?	?	?	?

Incomplete locales

These locales have shipping infrastructure in place but have not yet begun to localize Firefox OS.

Locale	Language	LangGroup	Font	Keyboard	L10n tool	# of devices	Shipping target
af	Afrikaans	Africa	?	?	Pootle	?	?	?
fi A	Finnish (Needs Repo)	?	?	?	Transifex	?	?	Yes
my	Burmese/Myanmar (Needs Repo)	Asia 1 ?	Yes	Yes	Pootle	?	?	?
lo	Lao	?	?	?	Pootle	?	?	?
zam	Miahuatian Zapotec (Needs Repo)	?	?	?	Pootle	?	?	?