L10n:Localization Process

End to End Firefox Localization Process Overview

This is an overview of the L10n process to localize Firefox from a process perspective. What we're attempting to convey is the step by step order that you as a localizer might expect when you take on the task of localizing Firefox into a new language. We're hoping this encourages you by providing more transparency in our process and indicating how and where (like expanding your community, doing local marketing, etc) we'd like to be more helpful to you. Feedback is welcomed at mic@mozilla.com or l10n-drivers@mozilla.org

START

Our common (Mozilla and Localizers) objective is to get a community formed and launch a new language/locale.

We all start here: (A) message from localizer to volunteer and/or a request to localize Firefox into a specific language. The decision process (set of questions we go through) that factually happens in this stage is this:

1 - Is the language real (Axel/Pascal handle this), if not (or it's contentious^), then we say "no" to the localizer and we should suggest they work to create a language pack^^^ or ship a variant of an existing build.^^

• ^ e.g., Bavarian, is this a dialect of German or another language
• ^^ closest examples of this are en-CA and en-ZA
• ^^^ we can offer hosting the language pack in CVS/AMO (not shipped.locales), however this is l10n-drivers team contentious and is a conversation that still needs to be addressed, the issue for all language packs is that they break minor updates; we need help from Smedberg (see bug 334136)

2 - if yes, check if there is a team that exists that you can join

3 - if no, evaluate the kind of skills you want to use (see more on this below), and what you need to continue (Axel does this in direct contact with localizer go to B for new suggestions)

Implications for Mozilla

• Decision to what extent we can give Localizers support

Implications for Localizer

• determining if you will operate as either an individual or team (often times teams are funded by local government initiatives)

(B) Mozilla then needs to get informed (or enhance our understanding) about the existing community and communicate the full set of skills required to be successful to localizers

Implications for Mozilla

• (Mic TO DO): Provide a documented description of full set of skills required:

• • 1-translation of web and client application content (this is considered a P1 to be a successful locale)
  • 2-people with engineering skills and people testing skills (P1)
  • 3-community development skills (P2)
  • 4-marketing and PR skills (P2)
  • 5-support (P3)

Implications for the Localizer

• Communicate the kind of work you'd like to do i.e.,your self-evaluation of your skill set, and where you are for a particular language in terms of all that's needed to support a new language

(Mic) TO DO cont'd: provide a set of documentation and graphical image to support this:

• - small pages
• - heavily interlinked
• - the graphical image should depict
• - with starting point being diagram or something similar depicting skill sets and how they can leverage other sources for support (other locales, communities)
• Need better job of describing community network that's needed
  • - best practices for building out skills in each area
  • - figure out likely places for recruiting e.g., University, other?

MIDDLE

Examples should be used to illustrate the stages between start and end = examples could be, Romania, Al, Farsi Beta 3 scenarios A = pre-Beta: in tree, not official B = Beta: in shipped-locales, not in all.html (examples Afrikaans, Belarusian, Georgian, Kurdish) C = language packs with no source (not in CVS) e.g., Breton

Two main scenarios in Middle A = have not been through a ship

• (Mic TO DO) Go through engineering requirements, and list here (from last week's discussion). In doing so we should also account for chaos in build process and create some level of evaluation of it's efficacy e.g., time it takes to add a new locale/language, an effective back up strategy

B = have been through ship and require some level of growth in team skills

• TO DO: content evaluation of assess health e.g., IRC conversations; Define decision step before official build status

END

An official build/(ongoing support) or a language pack (see description above)

Official build means that:

1- Minor updates, etc (Mozilla Corporation does this) Localizer - Initializer request and collaborate to complete Mozilla

• approve change requests (led by Axel)
• code/string/catch up approved by Axel
• branding by Mic
• web pages by Pascal

2- The localizer team may not have a full-skills team e.g., Marketing/PR TO DO: we need to determine how to better support them in this situation (Asa/Seth leading this) 3- Major updates done by Localizer

• could lose locales here which is a Bad outcome, this is due to loss of community people or lack of clear communication

The situation where we need to pull a locale from official ship status occurs when the localizer team is incapable of doing the next major update, these are our suggested options are: There is an option where the localizer doesn't meet the final deadline for official release in which case:

• next release/delay on being official build status

Mozilla we need to help them on community development and clearly communicate release schedule, etc. we need to know early the shape of the team for the release Localizers communicate their ongoing level of commitment

4-Mozilla supports testing

TO DO: get more transparent on our requirements and the process

• definitive tests, etc.

Items still to be discussed

• Locale vs. language there is a difference and it has been suggested by experts that we should be referring to languages vs locales, see Wikipedia for definition of locale
• AMO/MDC dev/mo

NOTES

• Would France be considered an ideal location because it has localizers that have support across all skill sets
• PL, DE, JA might be good examples of "regular" good locales (without paid support)