L10n:Localization Process

{DRAFT}

End to End Firefox Localization Process Overview

Our objective is to help you get a community formed in your country and launch as many new languages/locales as we can, our current goal is to get to 100. This wiki page is meant to give you, as a new volunteer, an overview of what’s involved from start to finish of a new build and then ongoing releases. We try to keep it short and sweet, (10 minutes of reading or less ;-).

We START the process when a volunteer asks to get involved. Once this happens a set of questions kick in to determine what the volunteer wants to do e.g., start a new language localization that hasn’t been done before, help an existing team, etc. If it’s a new language localization that will be created the volunteer, whom we now refer to as a localizer, begins the process of translating elements of the code into their language, the part of the process we call “the MIDDLE” (I know, we certainly need a more exciting set of names). There are a series of code reviews that happen and tests by both our Mozilla staff and the localizer to make sure the new build is working the way it’s supposed to. Once all of that is completed and the new build has been reviewed and tested, we move to the “END” of the process which while it seems by the name might indicate an end, is really the beginning of ongoing maintenance work to keep your new build current with major releases, like the upcoming Firefox 3 release as there are typically new features that can be made locale (check out this [Firefox3/L10n_Requirements|example]). The Mozilla team will ensure, in the case of a language deemed an “official build” (see more on that below) that your build is current for any minor releases like security upgrades, etc. So here we go with a much more detailed explanation of each stage…

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 - Assess the merits of the language, in particular, in terms of population and linguistic. Are there new users to be reached by adding this language that we can't reach with existing languages, or will there likely be an active user community forming around this language? (Axel/Pascal handle this), if the language is considered contentious by for example, linguistic scholars, 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.^

• ^ 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: create some content to describe how we might assess the "health" of a localization team and how we could better support them. One thought for doing this was to use IRC; we need to better define this 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)