L10n:B2G/Planning

From MozillaWiki
Jump to navigation Jump to search

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 excution 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 mechcanism 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 audiance similar to what we have on Firefox for Android. That's also a signficant 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
  • 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

chanlenges: -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 capabile of all 70, but other devices we will need to provide guidance on.

-performance degredation - 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 communcation 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?

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 diaglogs. 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.
  • ok is 6 letters (V redu - Slovenian) --- need more examples like this.
  • if the copy is not final, make that explict and get UX involved.

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? capitization?

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 testing one locale

Localization work has been estimated to last approx. 4 weeks, and should be (mostly) finished by the time we reach the "Soft l10n complete" date, that has previously been determined with Release Management. Once soft l10n complete date is reached, then QA starts intensive l10n testing. This intensive testing lasts 2 weeks. This period is then followed by 4 weeks of fixing and verifying bugs. We then reach the period known as String Freeze.

Typical calendar within FirefoxOS schedule
  • code freeze corresponds to our "soft string freeze": most strings have landed, even though we know some more will come.
  • 4 weeks after code freeze/soft string freeze is when we have our "Soft l10n complete". This is the date that we announce to localizers that they should have finished doing their chunk of l10n. They take around 4 weeks to do this work, so we have to be able to tell them when the soft l10n freeze is in advance.
  • when we hit "Soft l10n freeze", we start 2 weeks of Localization Run
  • then there's 4 weeks of fixing/verifying bugs
  • there are 4 weeks between Soft l10n freeze and hard string freeze
Concerning l10n testing for ONE locale, and assuming there are at least eight full-time testers on a locale, we have identified
  • 3 days of smoke testing, bug filing, etc
  • 4 weeks of fixing bugs and verifying them. This is approx. 2 weeks of devs/localizers going into their bugs to fix them, and approx. 2 weeks of us verifying them (full time).
Average number of bugs that turn up with this kind of testing
  • This is difficult to estimate, since there was no tracking bug for v1.1 l10n blockers per locale. For example, with Serbian Cyrillic (a new locale in v1.1), that had more bugs than other locales: given all the truncation issues that turned up, there was a total of 66 bugs.

We will have a better estimate once v1.2 testing will occur, and will update this page accordingly

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 transafex we also need to set up a mozilla project that improves navigation to all transafex work contributed to offical 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 fir FirefoxOS

need a better communication for requesting and tracking project setup on transafex 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 realitically be support.

Community Health Connecting to teams

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.

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 is needed 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?

Privacy Policy

  • Marketplace
  • FFOS

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 Bulgarian Europe4 ? Cyrillic (30 letters) ? ? 1.2
ca Catalan Europe1 ? QWERTY ? ? 1.1
cs Czech Europe4 ? QWERTZ ? ? 1.1
de German Europe3 ? QWERTZ ? ? 1.1
el Greek Europe1 ? Greek (phonetically similar to QWERTY) ? ? 1.1
es Spanish LATAM ? QWERTY Transifex ? 1.0.1
hr Croatian Europe2 ? QWERTZ ? ? 1.1
hu Hungarian Europe4 ? QWERTZ ? ? 1.1
it Italian Europe1 ? QWERTY Mozilla Translator+ Transvision 5 1.1
mk Macedonian Europe2 ? Cyrillic ? ? 1.2
nl Dutch Europe3 ? QWERTY ? ? 1.1
pl Polish Europe4 ? QWERTY ? ? 1.1
pt-BR Portuguese LATAM ? QWERTY ? ? 1.0.1
ro Romanian Europe4 ? QWERTZ ? ? 1.1
ru Russian Europe4 ? Cyrillic ? ? 1.1
sk Slovak Europe4 ? QWERTZ ? ? 1.2
sr-Cyrl Serbian (Cyrillic) Europe2 ? Cyrillic (+sr letters) ? ? 1.1
sr-Latn Serbian (Latin) Europe2 ? QWERTZ ? ? 1.1
tr Turkish Asia3 ? QWERTY modified Pootle ? 1.1

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.

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
sv-SE Swedish Europe3 ? ? ? ? ?
da Danish Europe3 ? ? ? ? ?
eo Esperanto Europe4 ? ? ? ? ?
fy-NL Frisian Europe3 ? ? ? ? ?
ga-IE Irish Europe3 ? ? ? ? ?
ja Japanese Asia1 ? ? ? ? ?
ko Korean Asia1 ? ? ? ? ?
pa Punjabi Asia2 ? ? ? ? ?
cy Welsh Europe3 ? ? ? ? ?
gd Gàidhlig - Scottish Gaelic Europe3 ? ? ? ? ?
ne-NP Nepali Asia3 ? ? ? ? ?
km Khmer Asia1 ? ? ? ? ?
si Sinhala Asia3 ? ? ? ? ?
th Thai Asia1 ? ? ? ? ?
ff Fulah / Pulaar-Fulfulde Africa ? ? ? ? ?
id Indonesian Asia1 ? ? ? ? ?
ast Asturian Europe1 ? ? ? ? ?
eu Basque Europe1 ? ? ? ? ?
lij Ligurian Europe1 ? ? ? ? ?
gu Gujarati Asia2 ? ? ? ? ?
ar Arabic Asia3 ? ? ? ? ?
hi-IN Hindi Asia2 ? ? ? ? ?
sq Albanian Europe2 ? ? ? ? ?
vi Vietnamese Asia1 ? ? ? ? ?
bn-IN Bengali-India Asia2 ? ? ? ? ?
ur Urdo Asia3 ? ? ? ? ?
ms Malay Asia1 ? ? ? ? ?
te Telugu Asia2 ? ? ? ? ?
he Hebrew Asia3 ? ? ? ? ?
et Estonian Europe4 ? ? ? ? ?
sl Slovenian Europe2 ? ? ? ? ?
ml Malayalam Asia2 ? ? ? ? ?
kn Kannada Asia2 ? ? ? ? ?
as Assamese Asia2 ? ? ? ? ?
be Belarusian Europe4 ? ? ? ? ?
bs Bosnian Europe2 ? ? ? ? ?
gl Galician Europe1 ? ? ? ? ?
ht Haitian creole Latam ? ? ? ? ?
or Odia Asia2 ? ? ? ? ?
zh-CN Simplified Chinese Asia1 QWERTY (PinYin, Chinese phonetic) ? ? 1.3
zh-TW Traditional Chinese Asia1 ? ZhuYin (Chinese phonetic) ? ? 1.3

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
Example Example Example ? ? Example ? Example
Example Example Example Example Example Example Example Example
Example Example Example Example Example Example Example Example

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
Example Example Example ? ? Example ? Example
Example Example Example Example Example Example Example Example
Example Example Example Example Example Example Example Example

Non-priority locales

These locales will not be on the list of priorities in the immediate future.

Locale Language LangGroup Font Keyboard L10n tool # of devices Shipping target
Example Example Example ? ? Example ? Example
Example Example Example Example Example Example Example Example
Example Example Example Example Example Example Example Example
Retrieved from "https://wiki.allizom.org/index.php?title=L10n:B2G/Planning&oldid=786061"