Confirmed users, Bureaucrats and Sysops emeriti
2,976
edits
L10n:Firefox in 2016: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 18: | Line 18: | ||
There's only one l10n repository (per locale) to localize all versions of Firefox we're currently shipping. Localizers have one place to add strings, and to supply fixes. Localizers can also freely change if they want to work on central or aurora. | There's only one l10n repository (per locale) to localize all versions of Firefox we're currently shipping. Localizers have one place to add strings, and to supply fixes. Localizers can also freely change if they want to work on central or aurora. | ||
=== For Developers === | |||
How do we get there? When changing existing strings, we need to add the new version, with a new ID like we used to. Just that we don't remove the old one. In detail, this only affects strings that are already on aurora. Strings that landed only after the last merge day can be safely removed. | |||
We'll have tests and/or hooks to help validate these rules. | |||
Each cycle, we'll go and remove strings that were only in the version(s) we stopped shipping. Having automation to support this process is part of the engineering efforts to implement this plan. | |||
=== For Localizers === | |||
Localizers will work on one repository, with compare-locales giving results against ESR, release, beta, and aurora. Instead of landing strings in different repositories, the l10n work lands in one repository, with the different en-US repos giving information about the urgency of the strings in question. | |||
== Localization Tool Changes == | |||
Parallel to the changes to how we expose strings to localize, and get them back, we're also expecting a series of changes coming to the tools that localizers actually use. | |||
''Interaction with VCS'' will become bidirectional. Localization tools like pontoon and pootle will save their work with attribution of the localizers to version control (hg). They will also read back changes from version control into their own databases. This will include support for refactorings and format changes. | |||
== Localization Infrastructure Changes == | |||
We'll see use of l20n rise incrementally in Firefox-related development. This will include a new paradigm for how to get strings from l10n. | |||
* Retrieving a localized string is fallible | |||
* Retrieving a localized string is asynchronous | |||
* Retrieving a localized string falls back over a list of languages at runtime | |||
Being able to fall back at runtime, and doing so without blocking mainthread IO, will decouple the localizations we ship from the binaries they're running against. | |||
== Installers == | |||
There will be experiments to create multilingual installers on all our platforms for desktop. The intent of these is to be performing at least as good as the language choice UX we offer on the web via language negotition there, and serving single-locale installers. | |||
== Not Changing == | |||
There are even things that don't change. | |||
=== Version Control === | |||
Version control and hg.mozilla.org in particular will remain the canonical source of truth for which localizations we ship, and in which state. | |||
=== Sign-off for Official Branding Builds === | |||
We'll continue to use a known-good revision for each localization to be shipped to channels with official branding. | |||
This allows us to do technical reviews based on source code diffs, and linguistic testing in non-branded builds in parallel. | |||
== TBD == | |||
A few topics haven't yet been discussed with all stakeholders, or don't have all data we need. For those, we need to have conversations and/or collect data. | |||
=== Shipping l10n updates to release/ESR === | |||
With the single repository containing release strings, we have the opportunity to ship updates to localizations to release audiences, in particular to ESR. | |||
* needs agreement with release management | |||
=== Aurora Channel === | |||
There's an open question which value the aurora channel provides to l10n going forward. Right now, it looks as if localization needs more time and not less. But that might be skewed by the fact that we're not exposing strings on a continuous basis. We should measure contributions frequencies in the new model, and reap benefits where they appear. | |||
== Bugs == | |||
As we get to having bugs that actually track engineering tasks, we should have a table below that shows the status of these. | |||