These are some of the interesting changes introduced in the last cycle.
Several strings were updated in Preferences, switching from “I/me” to ”You/your”. Depending on the way you translated them before, following closely English or using your own style, you might be able to reuse the existing translations.
Permission dialogs (sharing microphone, camera, location, etc.) have been redesigned to have a consistent layout and message. The result is that there are about 50 new strings to translate, in /browser and /toolkit (for password dialogs). You can use this website to test most permission dialogs.
There are several new strings related to managing WebExtensions-based add-ons. To give you an idea, the permission system is similar to the one available in a mobile OS, and you need to review them before installing or updating add-ons:
There’s a new string that is missing a comment (will be fixed, but not in time for this aurora cycle): “Open tabs” in pref_private_data_openTabs is a preference to clear open tabs, so “Open” is an adjective in this context, not a verb.
Localization is still broken for Debugger. In addition to that, a problematic changeset landed at the very end of the cycle: 7 strings changed without a new ID, and a few of them have issues (no plural form, one unclear). All issues should be fixed in the next Aurora cycle (this version of Debugger is enabled by default only on Nightly and Developer Edition).
There’s a certain excitement growing within Mozilla. We’ve spent the last year strengthening our core, making Firefox and other projects competitive, and eliminating pain points in the localization process. We improved our l10n quality control practices by holding l10n events (hackathons) to train localizers, creating language-specific style guides, and expanding our use of translation memory by enabling more projects on Pontoon. We’re now ready to expand on our l10n quality practices, support the release of a new Firefox, and transform localization into a continuous process in an effort to better support our users on localized builds of Firefox.
We’re preparing to contribute to this exciting time in Mozilla’s history by accomplishing the following long-term goals:
Implement a continuous localization process across all l10n projects.
Prepare Firefox desktop for implementation of l20n after Quantum.
Make sure that localization quality is a reason why users stay with Firefox.
Be aggressively competitive with existing mobile localizations and new mobile experiments.
Continuous localization is a localization process whereby strings are quickly delivered to localizers for translation and testing and then quickly delivered to product teams for release, all with minimal manual intervention. With Quantum coming to Firefox, we’re expecting a larger than average volume of strings to translate and deliver to the organization. Optimizing our tooling and processes to more seamlessly interact with version control systems (VCS) and automating relevant QA checks & tasks will expand and focus the l10n community’s impact on the most critical tasks that have brought them to Mozilla to contribute: rapidly making Firefox available to users in any language. We’ll know we’ve accomplished this when we’ve done these things:
improved our VCS interactions with Pootle & Pontoon,
incorporated a robust in-app notification system in Pontoon,
unified our dashboards,
and created the necessary training materials for localizers to know how to make a large impact within a world of continuous localization.
L20n in Firefox desktop
Measure and improve localization quality
Growth is the key word for 2017. Industry research tells us that users turn away from software that is poorly localized. As we’ve mentioned before, l10n quality is one of our highest priorities, however, we currently have no real way to measure quality. With performance, there are crash rate, startup time, and other metrics that can measure if a piece of software is well-developed. We’ve identified MQM as a similar metric that can help us measure the quality of localizations and inform how we recognize one another for good contributions and improve. We know we’ll be successful measuring and improving localization quality when we have done these things:
implemented MQM in Pontoon and Pootle,
improved localizer exposure to Bugzilla within tooling,
ensured that all l10n communities have and maintain style guides & glossaries for their language,
organize l10n workshops for all l10n communities shipping Mozilla localizations,
and create marketing materials & plans for us all to better evangelize Firefox in our languages.
Competition in mobile localizations
In 2017 Mozilla will be running multiple experiments in the mobile space. The continuous localization process will allow us the technical flexibility to support localization of these experimental projects. One way we can help make Firefox for Android and iOS a success is by offering users, at minimum, the same level of localization coverage as Chrome, Safari, and other competitors in this space. One advantage Mozilla has against Google, Apple, and others is our status as an open source project. Often we’re able to offer localizations of Firefox to users in more languages than they can thanks to you, the community. To be successful here, we plan to take these steps:
ship to users the same level of localization coverage as our competitors on mobile,
ship 5 more languages that they do not cover,
make it easier to clearly identify the set of strings required to ship a new localization within our l10n tools,
and work with the mobile teams to implement right-to-left (RTL) support in our mobile projects.
L10n workshops schedule
This year we’ll be holding six l10n community workshops (formerly called “hackathons”) in various locations around the world. These workshops will be larger than those we’ve held in the past, as they’ll involve inviting 3 localizers from anywhere between 9 – 23 l10n communities per workshop (27-69 localizers per workshop). The core focus areas for these workshops is four-fold:
Evangelizing localized products
Localization quality & testing
Training on l10n tool features
Each of these are areas that we’ve identified over the last couple of years of organizing l10n events as areas in which l10n communities worldwide need more help and support from the l10n-drivers. We’ll work with each l10n community to set goals around these four areas for their participation in workshops. We hope that those attending these workshops will return to their communities and share the lessons learned at the workshop they attended.
We plan to follow this schedule for this year’s l10n workshops for the following active l10n communities:
25-26 March | Barcelona
an, ast, ca, eu, gl, es-ES, fr, it, lij, pt-PT, rm, bg, bs, el, hr, hu, hy-AM, mk, ro, sl, sr
22-23 April | Taipei
ja, ko, zh-CN, zh-TW, id, km, ms, th, tl, vi, my, lo
6-7 May | Paris
ach, af, am, ff, son, xh, wo, az, ka, kk, tr, uz, ar, fa, he, ur, kab
12-13 August | Asunción
pt-BR, es-CL, es-MX, es-AR, eo, cak, gn, zam, trs
23-24 September | Berlin
br, cy, ga-IE, gd, de, en-GB, en-ZA, fy-NL, nl, uk, da, fi, is, nb-NO, nn-NO, sv-SE, dsb, cs, et, hsb, lv, lt, pl, sk, ru
7-8 October | Kolkata
bn-BD, bn-IN, gu, hi, kn, mr, ne, or, pa si, ta, te
The l10n-drivers will organize the workshops, including identifying localizers to invite from each community and seeking feedback and approval from each community’s leader(s). If you’re interested in following or participating in the planning, you can do so by following our projects in GitHub.
This is a big year for Mozilla as we aim to grow our influence. Thank you to all our community for your help. We’re looking forward to seeing what we can accomplish together as passionate, dedicated Mozillians.
At the end of last year we asked Pontoon users to participate in our survey in order to help us make better decisions on their behalf and shape the future of Mozilla’s translation tool.
Turnout exceeded our expectations: in the first 24 hours alone, 120 members of Mozilla localization community casted their votes. That gave us confidence to base Pontoon 2017 Roadmap on results of the survey. Let’s have a look at them!
154 people participated in the survey. They had to vote on each of this features from 1 to 5, so the minimum number of votes per idea was also 154.
Let’s see how survey results turn into Pontoon roadmap for the first quarter of the year:
In-app notifications. We’ll add the ability to send targeted notifications to relevant users on special events. For example, users who submitted translations to Firefox for iOS will receive a notification when new strings arrive. Author will be notified when new suggestion gets submitted for the string she translated. A few days before the deadline, we’ll send a reminder to team managers and translators of incomplete locales.
Priorities and deadlines. This is a requirement for some of the notifications described above, so it’s likely to get released earlier. For each project, we’ll show how important it is and when is the deadline to submit translations (if available). For projects like Mozilla.org (and in the future Firefox), we’ll also display priority and deadline information on a file level.
Screenshot-based localization. As goofy commented in the survey, 3 things are high priority: add context, provide context, show context 😉. What in-context localization brings to websites, screenshots could bring to product l10n. We’d like to explore that by designing a user interface for navigating strings by screenshots and displaying screenshot for any string. And we’ll try to do that as part of Google Summer of Code. Stay tuned!
Terminology and Glossary. The one and only Jotes already started integrating Microsoft Terminology into translation interface and we’re planning to ship that by the end of the quarter. As the first step towards creating Mozilla Terminology, we’ll also set up a localization project with terms extracted from various Mozilla projects. After Q1 we’ll focus on building a specialized functionality for creating, maintaining and translating terms.
L20n. While this hasn’t been called out as part of the survey, we have some work left to do regarding the implementation of the UI for advanced L20n features. A solid step forward has been made last year and now we have to land it and finalize the missing pieces.
The rest of the ideas from the survey will either get our attention post Q1 or will only get partially resolved during the first quarter. An example of the latter is merging Pontoon with our standalone dashboards (Elmo and Web Dashboard), which we’ll be effectivelly starting to do by adding support for priorities, deadlines and notifications, and also by outlining a plan to bring together the rest of the functionality.
And remember: even if the survey is now closed, you can always vote or comment on existing ideas or add new ones.
Here’s an outline of what is currently in Aurora this cycle for Firefox 52.
Current Aurora Cycle – Firefox 52
This is an unconventional cycle: it’s 2 cycles combined into one, to work around Holidays at the end of the year. It could be a great occasion to work on missing strings, or focus on testing if your locale is already in good shape.
Key dates for this cycle:
Beta (51): localization updates for already shipping locales must be completed before 11 January.
Aurora (52): localization updates must be completed before 23 January. That’s the Monday, also known as merge day, before the next release of Firefox.
Firefox Aurora desktop has 330 added strings (61 obsolete). About 48% of the new strings are for Developer Tools. The actual amount of strings you’ll need to translate will be lower, more on that later in the Developer Tools section.
Fennec Aurora has 55 new strings (29 obsolete). 5 new strings are Fennec-only (in /mobile).
There are currently no pending requests to uplift patches with strings to Aurora. There is ongoing work on Firefox stub installer that will probably need to land for Firefox 52, and there was a back-out during the weekend (strings landed and were removed for test failures). Given the exceptional length of the cycle, we might have a number of requests higher than usual. As we always do, we’ll carefully evaluate them one by one together with Release Drivers.
For further details on the new features you can check the release notes (they’re usually published a few days after release):
A migration script was run on all locales, excluding those working on l10n-central (eo, es-ES, fr, it, pl, ru), to move strings from the existing DTD files to the new .properties files. 115 strings were moved in the process, reducing the number of missing strings for Firefox desktop to 215.
We also worked together with Pootle’s tech team to make sure that these changes will be imported in the tool.
Strings were automatically moved to netmonitor.properties, boxmodel.properties, font-inspector.properties, inspector.properties (all in /devtools/client). All obsolete DTD files were removed.
The new Debugger is now localizable, even if there are still some hardcoded strings to fix.
We added a new view in Transvision to display empty strings diverging between English and the requested locale. In other words, it displays a string that is empty in English but not in the locale, and a string that is empty in the locale but not in English.
Empty strings are not a rarity in Mozilla products:
When creating a sentence with a link, 3 strings are used: before_link + link + after_link. English doesn’t need the part before or after the link, but that’s useful for other languages, so it’s kept empty in English. It’s expected for some locales to have a different behavior than English.
There are secondary commandkeys or accesskeys, or special values that are supposed to remain empty for most locales.
Pootle will report these empty strings as untranslated: for the first type of strings you can use the special control displayed under the text area to insert a “zero width non-joiner” character. That doesn’t necessarily work for the second type, so you’re invited to test to avoid introducing strange behaviors.
Related to this special values, there are several locales with wrong values for the following keys.
# LOCALIZATION NOTE (intl.charset.detector):
# This preference controls the initial setting for the character encoding
# detector. Valid values are ja_parallel_state_machine for Japanese, ruprob
# for Russian and ukprob for Ukrainian and the empty string to turn detection
# off. The value must be empty for locales other than Japanese, Russian and
# LOCALIZATION NOTE (isRTL):
# Leave this entry empty unless your language requires right-to-left layout,
# for example like Arabic, Hebrew, Persian. If your language needs RTL, please
# use the untranslated English word "yes" as value
A lot of improvements to Mozilla l10n tools and process have come throughout 2016. We’ve deeply enjoyed connecting with members of the community to learn what other improvements you would like to see in l10n. For the rest of the year, the l10n team has a number of goals we’re working toward accomplishing by 1 January 2017:
Land L20n in Firefox desktop,
Implement cross-channel localization for Firefox and Firefox for Android,
Track all project statuses in GitHub Projects and report frequently,
The last weekend of August saw the largest localization hackathon event the l10n-drivers ever organized. Thirty-four community contributors representing 12 languages from 13 East and Southeast Asian countries journeyed to Kuala Lumpur, Malaysia on Friday, August 26. Jeff, Flod, Gary Kwong and I arrived in time for the welcome dinner with most of the community members. The restaurant, LOKL Coffee, was ready for a menu makeover and took the opportunity to use this Mozilla event to do just that. A professional photographer spent much of the evening with us snapping photos.
We started off Saturday morning with Spectrogram, where l10n contributors moved from one side of the room to another to illustrate whether they agreed or disagreed with a statement. Statements help us understand each community’s preferences to address localization requests. An example: There are too many translation/localization tasks for me to keep up; I want to work on 2000 strings sliced up in 1 year, twice, 6 weeks, 4 weeks, weekly, every other day, daily.
Jeff, the newly appointed localization manager, updated everyone on l10n organization change; the coming attraction of the l20n development; Pontoon as one of the centralized l10n tools; and the ultimate goal of having a single source of l10n dashboard for the communities and l10n project managers.
Flod briefed on the end of Firefox OS and the new initiatives with Connected Device. He focused on Firefox primarily. He discussed the 6-week rapid release cycles or cadence. He also covered the five versions of Firefox: Aurora, nightly, beta, release, and ERS. He described the change to a single source of repository, allowing strings move to production sooner. Firefox for iOS and Android were also presented. It was welcome news that the localized product can be shipped through automatic signoff, without community’s involvement.
I talked about the importance of developing a style guide for each of the languages represented. This helps with onboarding new comers, consistency among all contributors and sets the style and tone for each of the Mozilla products. I also briefly touched upon the difference between brand names and product names. I suggested to take this gathering as an opportunity to work on these.
For the rest of the weekend, our communities worked through the goals they set for ourselves. Many requested to move their locales to Pontoon, causing a temporarily stall in sync. Others completed quite a few projects, making significant advances on the dashboard charts. Even more decided to tackle the style guides, referencing the template and leveraging information from established outlets. When the weekend was over, nine communities reported to have some kind of draft versions, or modified and updated an existing one. Other accomplishments included identifying roles and responsibilities; making plans for meetup for the rest of the year; tool training; improving translation quality by finding critical errors; updating glossaries; completing some high priority projects.
The weekend was not just all work, but filled with cultural activities. Our Saturday dinner at Songket Restaurant was followed by almost an hour of Malaysian cultural dances from across the country, showcasing the diverse cultures that made up Malaysia. Many community members were invited to the stage to participate. It was a fun evening filled with laughter. Our Sunday dinner was arranged inside Pasar Seni, or the Central Market, a market dating back to 1888. It is now filled with shops and restaurants, giving all visitors a chance to take home some souvenirs and fond memories. Many of us visited the near by Pedaling Street, sampling tropical fruits, including Durian, made in all shapes and forms.
Putting together the largest l10n hackathon ever is a big achievement and lots of credit goes to our local support. A big thanks to our Malaysian community, led by Syafiq, who was our eyes and ears on the ground from day one, planning, selecting the venue location, advising us on restaurants, lodging, transportation and cultural events. Not only we accomplished what we set out to do, we did it safely, we all had fun and we made more friends. Also a shout-out to Nasrun, our residence photographer for documenting the weekend through his lens. And a thank you to everyone for sharing a very special and productive weekend with fellow Mozillians! See you next time at another hackathon!
One of the main goals of Pontoon is lowering barriers to entry. Especially for end users (mainly localizers), but also for contributors to the codebase, since many of our localizers have a developer background.
I’m happy to acknowledge that in the last 30 days there has been more activity from volunteer contributors in Pontoon development than ever before! Let’s have a closer look at what have they been working on:
Last month’s Pontoon contributors
Michal came up with the idea to highlight matches in original and translated strings when searching in the sidebar. He created a patch, but couldn’t finish it due to his school duties. It was taken over by Jarek, who earlier played a great role in reviewing the original patch by Michal.
Being only 14 years old, Michal is the youngest Pontoon contributor!
Jarek Śmiejczak (jotes)
Since he became an active Pontoon contributor over a year ago, Jarek has evolved from being not just a great developer but also a fantastic mentor; helping onboard new contributors and review their work. One way or another, he’s been involved with all bugs and features listed in this blog post.
Of course that doesn’t mean he stopped contributing code. On the contrary, he just completed a Firefox Accounts based authentication support which will soon replace Persona. And, he’s already busy working on bringing terminology support to Pontoon too.
As the new leader of the Bulgarian localization team, Stoyan takes his duties very professionally. He started by creating a vector version of Pontoon logo and changing the copy.
Later on he created a Firefox Add-On called Pontoon Enhanced, which can add new features to Pontoon before they are deployed or even implemented in the application. It’s basically a Test Pilot for Pontoon.
As an agile bug reporter, Michal has been one of the most valuable early adopters of Pontoon. Now he has decided to take a step further.
He set up his local Pontoon instance, fixed a few developer documentation bugs along the way and provided a patch that fixes one of the bugs he reported. It allows us to properly detect placeables of form %(thisIsVariable)s.
I consider myself lucky to be working with this great team. It is particularly valuable to see contributions coming from people who actually use the product. This is what the power of the open Web looks like!
Here’s an outline of what is currently in Aurora this cycle for Firefox 50 and some information on the accomplishments of the l10n Community during the previous cycle.
Current Aurora Cycle – Firefox 50
Key dates for this cycle:
Beta (49): localization updates for already shipping locales must be completed before 31 Aug. For reference, the date is roughly 2 weeks before the next release date, and it’s the last good day to include your updates into a Beta build.
Aurora (50): localization updates must be completed before 12 September. That’s the Monday, also known as merge day, before the next release of Firefox.
Firefox Aurora desktop has 155 added strings (125 obsolete). About 43% of the new strings are for Developer Tools.
Fennec Aurora has 88 new strings (61 obsolete). 11 new strings are Fennec-only (in /mobile).
There are currently no pending requests to uplift patches with strings to Aurora.
For further details on the new features you can check the release notes (they’re usually published a few days after release):
Noteworthy events for Firefox 48 (release date 3 Aug):
52 locales, corresponding to 63% of our shipping locales, signed off updates for Firefox 48 on desktop.
48 locales, corresponding to 72% of our shipping locales, signed off updates for Fennec 48 on Android.
As recently announced, localizers are not going to request sign-offs anymore for Firefox and Fennec, l10n-drivers will sign-off and review any update landing in the repository, for both Aurora and Beta.
For this reason we’re probably not going to include this section in the next cycle reports, while we determine more meaningful metrics to track localization activity.
Noteworthy Changes Available in Aurora
These are some of the interesting changes introduced in the last cycle.
The new Containers feature is not enabled outside of Nightly (it might be included in a future Test Pilot experiment). If you want to test it, you need to manually switch the preference privacy.userContext.enabled to True.
As explained in the previous report, team is starting to use a new way to define keyboard shortcuts (not accesskeys), adopting a syntax similar to Electron.
You should not translate fragments like “CmdOrCtrl”, “CmdOrCtrl+Plus” (Plus indicates the ‘+’ key), “CmdOrCtrl+Shift+D”. Also a reminder that you should not be changing shortcuts in general, unlike accesskeys, unless the default keyboard layout for your locale doesn’t include that specific key, or combination of keys. Translating these keys will result in the tools being broken.
Several developer tools are also moving strings from .DTD to .properties, it should be expected to have a perfect match in TM tools like Pontoon & Pootle between old and new strings. For example:
Translated reference entities and untranslated labels
In .DTD files, a string can contain a reference to another entity in the form of &another_entity_name; (note the ampersand at the beginning and the semicolon at the end). These are references to other string IDs and should not be translated.
Example from Fennec:
You can always turn this off in &settings; under &pref_category_general;.
A few locales translated the first &settings;, generating an error. It’s also good to remember that these errors break the multi-locale Android build for all locales, en-US included, and that’s why you will see someone from l10n-drivers committing a fix directly in tools (Pontoon, Pootle) or Mercurial. Please remember to keep an eye on the dashboard page for your locale and verify errors and warnings.
On the other hand, Pootle displays a string with an accesskey as &Show: the label is “Show”, the accesskey is “S” (the character after the ampersand). Note that there’s no semicolon at the end. This has to be translated, and dropping the ampersand will make the accesskey fallback to English. Never add the accesskey to your label, e.g. “Show (S)”. For further details about accesskeys, see this discussion on dev-l10n.
Thanks to everyone for your dedication and hard work this last cycle. If you note anything missing in these reports, or would like to see other information included, please let me know.
L20n is a new localization framework for Firefox and Gecko. Here’s what you need to know if you’re a Firefox front-end developer.
Gecko’s current localization framework hasn’t changed in the last two decades. It is based on file formats which weren’t designed for localization. It offers crude APIs. It tasks developers with things they shouldn’t have to do. It doesn’t allow localizers to use the full expressive power of their languages.
L20n is a modern localization and internationalization infrastructure created by the Localization Engineering team in order to overcome these limitations. It was successfully used in Firefox OS. We’ve put parts of it on the ECMA standardization path. Now we intend to integrate it into Gecko and migrate Firefox to it.
Overview of How L20n Works
What problems L20n solves?
The current localization infrastructure is tightly-coupled: it touches many different areas of the codebase. It also requires many decisions from the developer. Every time someone wants to add a new string they need to go through the following mental checklist:
Is the translation embedded in HTML or XUL? If so, use the DTD format. Be careful to only use valid entity references or you’ll end up with a Yellow Screen of Death. Sure enough, the list of valid entities is different for HTML and for XUL. (For instance …
is valid in HTML but not in XUL.)
Does the translation depend on a number in any of the supported languages? If so, use the PluralForm.jsm module to choose the correct variant of the translation. Specify all variants on a single line of the .properties file, separated by semicolons.
Does the translation comprise HTML elements? If so, split the copy into smaller parts surrounding the HTML elements and put each part in its own translation. Remember to keep them in sync in case of changes to the copy. Alternatively write your own solution for replacing interpolation specifiers with HTML markup.
What a ride! All of this just to add a simple You have no new notifications message to the UI. How do we fix this tight-coupled-ness?
L20n is designed around the principle of separation of concerns. It introduces a single syntax for all use-cases and offers a robust fallback mechanism in case of missing or broken translations.
Let’s take a closer look at some of the features of L20n which mitigate the headaches outlined above.
In addition to DTD and .properties files Gecko currently also uses .ini and .inc files for a total of four different localization formats.
L20n introduces a single file format based on ICU’s MessageFormat. It’s designed to look familiar to people who have previous experience with .properties and .ini. If you’ve worked with .properties or .ini before you already know how to create simple L20n translations.
Fig. 1. A primer on the FTL syntax
A single localization format greatly reduces the complexity of the ecosystem. It’s designed to keep simple translations simple and readable. At the same time it allows for more control from localizers when it comes to defining and selecting variants of translations for different plural categories, genders, grammatical cases etc. These features can be introduced only in translations which need them and never leak into other languages. You can learn more about L20n’s syntax in my previous blog post and at http://l20n.org/learn. An interactive editor is also available at https://l20n.github.io/tinker.
Separation of Concerns: Plurals and Interpolation
In L20n all the logic related to selecting the right variant of the translation happens inside of the localization framework. Similarly L20n takes care of the interpolation of external variables into the translations. As a developer, all you need to do is declare which translation identifier you are interested in and pass the raw data that is relevant.
Fig. 2. Plurals and interpolation in L20n
In the example above you’ll note that in the BEFORE version the developer had to manually call the PluralForm API. Furthermore the calling code is also responsible for replacing #1 with the relevant datum. There’s is no error checking: if the translation contains an error (perhaps a typo in #1) the replace() will silently fail and the final message displayed to the user will be broken.
Separation of Concerns: Intl Formatters
L20n builds on top of the existing standards like ECMA 402’s Intl API (itself based in large part on Unicode’s ICU). The Localization team has also been active in advancing proposals and specification for new formatters.
L20n provides an easy way to use Intl formatters from within translations. Often times the Intl API completely removes the need of going through the localization layer. In the example below the logic for displaying relative time (“2 days ago”) has been replaced by a single call to a new Intl formatter, Intl.RelativeTimeFormat.
Fig. 3. Intl API in use
Separation of Concerns: HTML in Translations
L20n allows for some semantic markup in translations. Localizers can use safe text-level HTML elements to create translations which obey the rules of typography and punctuation. Developers can also embed interactive elements inside of translations and attach event handlers to them in HTML or XUL. L20n will overlay translations on top of the source DOM tree preserving the identity of elements and the event listeners.
Fig. 4. Semantic markup in L20n
In the example above the BEFORE version must resort to splitting the translation into multiple parts, each for a possible piece of translation surrounding the two <label> elements. The L20n version only defines a single translation unit and the localizer is free to position the text around the <label> elements as they see fit. In the future it will be possible to reorder the <label> elements themselves.
Resilient to Errors
L20n provides a graceful and robust fallback mechanism in case of missing or broken translations. If you’re a Firefox front-end developer you might be familiar with this image:
Fig. 5. Yellow Screen of Death
This errors happens whenever a DTD file is broken. The way a DTD file can be broken might be as subtle as a translation using the … entity which is valid in HTML but not in XUL.
In L20n, broken translations never break the UI. L20n tries its best to display a meaningful message to the user in case of errors. It may try to fall back to the next language preferred by the user if it’s available. As the last resort L20n will show the identifier of the message.
L20n allows us to re-think major design decisions related to localization in Firefox. The first area of innovation that we’re currently exploring is the experience of changing the browser’s UI language. A runtime localization framework allows the change to happen seamlessly on the fly without restarts. It will also become possible to go back and forth between languages for just a part of the UI, a feature often requested by non-English users of Developer Tools.
Another innovation that we’re excited about is the ability to push updates to the existing translations independent of the software updates which currently happen approximately every 6 weeks. We call this feature Live Updates to Localizations.
We want to decouple the release schedule of Firefox from the release schedule of localizations. The whole release process can then become more flexible and new translations can be delivered to users outside of regular software updates.
L20n’s goal is to improve Mozilla’s ability to create quality multilingual user interfaces, simplify the localization process for developers, improve error recovery and allow us to innovate.
The migration will result in cleaner and easier to maintain code base. It will improve the quality and the security of Firefox. It will provide a resilient runtime fallback, loosening the ties between code and localizations. And it will open up many new opportunities to innovate.
This blog is protected by Dave's Spam Karma 2: 33820 Spams eaten and counting...