L10n:Localization Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 24: Line 24:




==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==
==MIDDLE==

Revision as of 18:05, 1 May 2007

{DRAFT}

End to End Firefox Localization Process Overview

Our L10n 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 ;-).

Very simple overview

The 5 step process to localizing Firefox. Click on the links to get the more detailed view:

1 Volunteer appears and community STARTs to form

  • realization that Firefox needs a new language
  • if we form a community we can solve this problem
  • get ready to turn our will into action and be reviewed by team

2 Preparation for creating your language begins and effectively you've entered the MIDDLE of the process

  • review skills required (help building your team)

3 Localizations gets plugged into our build/release process for automation

  • automation happens here

4 Builds are prepared for final release and testing (what we refer to as Beta)

  • fix bugs, get ready for many reviews, get plugged in and prepare yourself
  • daily builds start happening and this is an iterative process to get a candidate for final release

5 "Releases happens" for your locale - the END

  • offered automatically to people coming to our site
  • celebration/party
  • tell other people about your experience



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)
Retrieved from "https://wiki.mozilla.org/index.php?title=L10n:Localization_Process&oldid=55762"