|
|
| Line 18: |
Line 18: |
| * fix bugs, get ready for many reviews, get plugged in and prepare yourself | | * 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 | | * 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 | | 5 "Releases happens" for your locale - the [[L10n:Localization_Process_End| END]] |
| * offered automatically to people coming to our site | | * offered automatically to people coming to our site |
| * celebration/party | | * celebration/party |
| * tell other people about your experience | | * 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)
| |