Planet Mozilla L10N

September 30, 2019

Mozilla L10n Blog

Here comes Pontoon’s new Translate application

If you have contributed to Mozilla’s localization in the past few years, chances are high that you have interacted with Pontoon’s translation page. That page is the most important one of the Pontoon web app, as it is where people can create, review and manage translations for most of the products Mozilla makes. Today we are happy to announce that we are soon going to release an entirely re-written version of that page, nicknamed “Translate.Next”. This post shares all the details about this release, and should answer the questions you might have about it.

What is Translate.Next?

Pontoon was started in 2011, and has grown quite a lot since then. Most of the back-end, using Python and Django, has been kept up-to-date and is still doing mostly fine, but the front-end, and specifically the Translate app, is in a terrible shape. Our code has accumulated a lot of technical debt, and is very difficult to maintain and evolve.

After I joined the Pontoon team in the summer of 2017, I spent some time auditing the translate application code, and it quickly became clear to me that a full rewrite would bring a lot of value. Here are some of the benefits this brings:

  1. removing technical debt and making our code saner;
  2. adding better test coverage for our front-end;
  3. enabling the localization of Pontoon, starting with the Translate page;
  4. structurally enabling some of the many improvements our users have been asking for.

Over the last year and a half, Matjaž and myself have been spending a lot of our time working on rewriting the Translate page from scratch, using more recent, better adapted technologies, making our code a lot more modular and maintainable. (If you are interested in knowing more about the technologies we used, it is described in our github repository — there’s some React, redux, Jest and Flow in there. )

How is it different from the current page?

Translate.Next is just the first part of our effort to improve Pontoon’s translation page, while the second part will be the functional changes we’ll start working on now. For the time being though, translation page should be as much as possible the same in terms of features, interface and usability as the current Translate page. We have done our best to reproduce the same layouts and behaviors so that the switch would be as transparent as possible to everyone.

However, there are a few things that we decided to change already. The most visible of them is the navigation menu, which now requires less clicks to navigate localizable resources thanks to the removal of the infamous Go button.

Here’s what it looks like now:

Pontoon's current Translate navigation bar

And here is what it looks like with Translate.Next:

Pontoon's new Translate navigation bar

The other changes should be fairly inoffensive. We have removed the Tab shortcut in the Editor, as well as support for in-context localization, as it seems both were hardly ever used. It’s also not possible to resize the columns yet, as we have plans to evolve the page layout very soon and the behavior of this feature will change.

If you notice something not mentioned here is different, then it’s very probably a bug, and we would like to hear from you. More on that later in this post!

When will I see the new page?

We intend to do a “rollout” release, meaning that we will turn the feature on for a small percentage of users, and then will increase that number over time until we reach 100%. The users who get to experience the new Translate.Next page will be chosen randomly by a tool we use.

However, we can, and will, add exceptions. Namely, everyone who participated in our last round of testing and has Translate.Next turned on will keep it on. And we can add more exceptions, so if you don’t want to wait for your turn, you can simply contact us (Adrian or Matjaž) with the email address you use to log in to Pontoon, and we’ll give you access.

Note that we will not allow users to opt out, unless there is a very good reason for that. We will take your feedback and categorize it into two buckets: regressions, and the rest. Regressions are big issues that prevent localizers from performing their tasks. They are blockers to advancing Mozilla’s mission and thus we want to take quick action to unblock people if that happens. A regression will very likely mean that we will turn Translate.Next off for everyone until we have fixed it.

Every other issue will be treated as a bug, and we will do our best to solve these in a timely manner, but we kindly ask that you bear with us in the meantime. We do not want to revert everyone back to the old Translate page for a problem that is not blocking you.

The release schedule, baring we don’t find any regressions, is as follow:

Wednesday, October 2: release to a random 10% of users.
Monday, October 7: release to a random 30% of users.
Wednesday, October 9: release to a random 50% of users.
Monday, October 14: release to all users.

Bugs and regressions found along the way will delay that schedule. We will keep you updated if any such thing happens.

How do I report issues?

If you notice that something works differently than before, or if you find that something is broken, we strongly encourage you to tell us as soon as possible. There are several ways you can do that.

The easiest is to simply add a comment here, below this blog post. Please write a description of your problem, and ideally steps to reproduce it. When commenting, make sure to put a valid email address in the “E-mail” field so that we can reach out to you if we need more details.

If you enjoy using the Mozilla Community discourse forum, you can also describe your issue in the dedicated Translate.Next topic.

And finally, if you are comfortable using Bugzilla, you can go straight there and file a bug.

If you want to check our list of known issues, or follow the status of a reported bug, we keep an updated list on Pontoon’s Wiki page.

Other questions

How do I know I’m using Translate.Next?

There are 2 ways to know: first, the menu will look a bit different (see above). Second, and probably simpler: there will be a message in the top right corner saying you are using Translate.Next. 🙂

Can I revert back to the old Translate page?

No, once you’re on Translate.Next, the only way to get back to the old Translate page is if we find a critical regression and revert everyone. We cannot revert individuals to the old page.

Can I opt-in to Translate.Next?

Yes, absolutely. Just contact us (Adrian or Matjaž) asking that you want in, and give us the email address that you use to login on Pontoon.

Let’s release!

Thank you for helping with this release. We hope you will enjoy the new Translate page, and all the cool changes we will be able to make in the future thanks to that. And keep an eye out for the new page to show up on your Pontoon. 😉

September 30, 2019 04:35 PM

September 19, 2019

Mozilla L10n Blog

L10n Report: September Edition

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet. 

Welcome!

New localizers

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New community/locales added

New content and projects

What’s new or coming up in Firefox desktop

As anticipated in the previous edition of the L10N Report, Firefox 70 is going to be a large release, introducing new features and several improvements around Tracking Protection, privacy and security. The deadline to ship any updates in Firefox 70 is October 8. Make sure to test your localization before the deadline, focusing on:

Be also mindful of a few last-minute changes that were introduced in Beta to allow for better localization.

If your localization is missing several strings and you don’t know where to start from, don’t forget that you can use Tags in Pontoon to focus on high priority content first (example).

Upcoming changes to the release cycle

The current version of the rapid release cycle allows for cycles of different length, ranging from 6 to 8 weeks. Over two years ago we moved to localize Nightly by default. Assuming an average 6-weeks cycle for the sake of simplicity:

A few days ago it was announced that Firefox is progressively moving to a 4-weeks release cycle. If you’re focusing your localization on Nightly, this should have a relatively small impact on your work:

The cycles will shorten progressively, stabilizing to 4 weeks around April 2020. Firefox 75 will be the first one with a 4-weeks cycle in both Nightly and Beta.

While this shortens the time available for localization, it also means that the schedule becomes predictable and, more importantly, localization updates can ship faster: if you fix something in Beta today, it could take up to 8 weeks to ship in release. With the new cycle, it will always take a maximum of 4 weeks.

What’s new or coming up in web projects

Firefox Accounts

A lot more strings have landed since the last report.  Please allocate time accordingly after finishing other higher priority projects. An updated deadline will be added to Pontoon in the coming days. This will ensure localized content is on production as part of the October launch.

Mozilla.org

A few pages have been recently added and more will be added in the coming weeks to support the major release in October. Most of the pages will be enabled in de, en-CA, en-GB, and fr locales only, and some can be opted-in. Please note, Mozilla staff editors will be localizing the pages in German and French.

Legal documentation

We have quite a few updates in legal documentation. If your community is interested in reviewing any of the following, please adhere to this process: All change requests will be done through pull requests on GitHub. With a few exceptions, all the suggested changes should go through a peer review for approval before the changes go to production.

MDN & SuMo

Due to recent merge to a single Bengali locale on the product side, the articles were consolidated as well. For the overlapped articles, the ones selected were based on criteria such as article completion and the date of the completion.

What’s new or coming up in SuMo

Newly published articles for Fire TV:

Newly published articles for Preview:

Newly published articles for Firefox for iOS:

Improving TM matching of Fluent strings

Translation Memory (TM) matching has been improved by changing the way we store Fluent strings in our TM. Instead of storing full messages (together with their IDs and other syntax elements), we now store text only. Obviously, that increases the number of results shown in the Machinery tab, and also makes our TMX exports more usable. Thanks to Jordi Serratosa for driving this effort forward! As part of the fix, we also discovered and fixed bug 1578155, which further improves TM matching for all file formats.

Faster saving of translations.

As part of fixing bug 1578057, Michal Stanke discovered a potential speed up for saving translations. Specifically, improving the way we update the latest activity column in dashboards resulted in a noticeable speedup of 10-20% for saving a translation. That’s a huge win for an operation that happens around 2,000 times every day. Well done, Michal!

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

September 19, 2019 03:34 PM

August 14, 2019

Mozilla L10n Blog

L10n Report: August Edition

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet. 

Welcome!

New localizers:

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New community/locales added

New content and projects

What’s new or coming up in Firefox desktop

We’re quickly approaching the deadline for Firefox 69. The last day to ship your changes in this version is August 20, less than a week away.

A lot of content targeting Firefox 70 already landed and it’s available in Pontoon for translation, with more to come in the following days. Here are a few of the areas where you should focus your testing on.

about:logins

This is the new password manager for Firefox. If you don’t plan to store the passwords in your browser, you should at least create a new profile to test the feature and its interactions (adding logins, editing, removing, etc.).

Enhanced Tracking Protection (ETP) and Protection Panels

This is going to be the main focus for Firefox 70:

With ETP there will be several new terms to define for your language, like “Cross-Site Tracking Cookies” or “Social Media Trackers”. Make sure they’re translated consistently across the products and websites.

The deadline to ship localization for Firefox 70 will be October 8.

What’s new or coming up in mobile

It’s summer vacation time in mobile land, which means most projects are following the usual course of things.

Just like for Desktop, we’re quickly approaching the deadline for Firefox Android v69. The last day to ship your changes in this version is August 20.

Another thing to note is that we’ve exposed strings for Firefox iOS v19 (deadline TBD soon).

Other projects are following the usual continuous localization workflow. Stay tuned for the next report as there will be novelties then for sure!

What’s new or coming up in web projects

Firefox Accounts

A lot of strings landed earlier this month. If you need to prioritize what to localize first, look for string IDs containing `delete_account` or `sync-engines`. Expect more strings to land in the coming weeks.

Mozilla.org

The following files were added or updated since the last report.

The navigation.lang file has been made available for localization for some time. This is a shared file, and the content is on production whether the file is fully localized or not. If this is not fully translated, make sure to give this file higher priority to complete soon.

What’s new or coming up in Foundation projects

More content from foundation.mozilla.org will be exposed to localization in de, es, fr, pl, pt-BR over the next few weeks! Content is exposed in different stages, because the website is built using different technologies, which makes it challenging for localization. The main pages will be available in the Engagement project, and a new tag can help have a look at them. Other template strings will be exposed in a new project later.

donate.mozilla.org is getting an update too! The website is being rebuilt from the ground up with a new system that will make it easier to maintain. The UI won’t change too much, so the copy will mostly remain the same. However, it won’t be possible to migrate the current translations to the new system, instead we will heavily rely on Pontoon’s translation memory.
Once the new website is ready, the current project in Pontoon will be set to “read only” mode during a transition period and a new project will be enabled.

Please make sure to review any pending suggestion over the next few weeks, so that they get properly added to the translation memory and are ready to be reused into the new project.

What’s new or coming up in SuMo

Newly published articles:

What’s new or coming up in Pontoon

The Translate.Next work moves on. We hope to have it wrapped up by the end of this quarter (i.e., end of September). Help us test by turning on Translate.Next from the Pontoon translation editor.

Newly published localizer facing documentation

Events

Friends of the Lion

Know someone in your l10n community who’s been doing a great job and should appear here? Contact one of the l10n-drivers, and we’ll make sure they get a shout-out (see list at the bottom)!

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

August 14, 2019 06:00 PM

July 15, 2019

Mozilla L10n Blog

Q3 2019 objectives for Mozilla localization

Every three months, the l10n-drivers dedicate a couple of weeks to review progress made on objectives from the past three months (or quarter) and plan new objectives for the next quarter. Historically, we haven’t published much about these objectives, but that’s something I intend to change with this blog post. Transparency is a priority to this team and as such, I plan to discuss more openly the non-confidential, ongoing work that the team is undertaking with each quarter.

Internally, we follow a goal-setting methodology known as OKR (Objective, Key Result). OKRs are intended to be set at each level of an organization. Team OKRs should naturally nest themselves into higher level OKRs. According to this methodology, a team identifies a vision statement (aka Objective) and then 2-5 metrics to determine whether that vision has been met (aka Key Results). Teams try to limit their Objectives to only 3-5 for a specified period of time (in our case, three months). Once these OKRs are set, the team undertakes various initiatives/projects to accomplish the metrics set in each Key Result.

Today, we’ve wrapped up OKR planning for Q3 2019 (July – September) and I’d like to share with you what our core focus will be for the next three months (in no order of priority):

By the end of Q3 we can…

Objective: Optimize the localization vendor workflow for internal teams.

As measured by…

Objective: Measure locale manager engagement to discover sustainability threats for intervention.

As measured by…

Objective: Be ready to rapidly develop and test new features in the Pontoon translation workbench.

As measured by…

Objective: Scale for the growing Fluent community.

As measured by…

Objective: Communicate data around Skyline (Firefox milestone release) l10n status to stakeholders.

As measured by…

At the end of Q3, I plan to report on our progress on each of these, noting which were achieved, which were dropped, and which may carry over into Q4. If you have any questions about these, please reach out to the l10n-drivers.

July 15, 2019 06:03 PM

July 04, 2019

Mozilla L10n Blog

L10n report: July edition

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet. 

Welcome!

New localizers

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New community/locales added

New content and projects

What’s new or coming up in Firefox desktop

As usual, let’s start with some important dates:

Firefox 69 has been a lightweight release in terms of new strings, with most of the changes coming from Developer Tools. Expect a lot more content in Firefox 70, with particular focus on the Password Manager – integrating most of the Lockwise add-on features directly into Firefox – and work around Tracking Protection and Security, with brand new about pages.

What’s new or coming up in mobile

Since our last report, we’ve shipped the first release of Firefox Preview (Fenix) in 11 languages (including en-US). The next upcoming step will be to open up the project to more locales. If you are interested, make sure to follow closely the dev.l10n mailing list this week. And congratulations to the teams that helped make this a successful localized first release!

On another note, Firefox for iOS deadline for l10n work on v18 just passed this week, and we’re adding two new locales: Finnish and Gujarati. Congratulations to the teams!

What’s new or coming up in web projects

Keep brand and product names in English

The current policy per branding and legal teams is that the trademarked names should be left unchanged. Unless indicated in the comments, brand names should be left in English, they cannot be transliterated or declined. If you have any doubt, ask through the available communication channels.

Product names such as Lockwise, Monitor, Send, and Screenshot, to name a few, used alone or with Firefox, should be left unchanged. Common Voice is also a product name and should remain unchanged. Pocket is a trademark and must remain as is too. Locale managers, please inform the rest of the communities on the policy especially to new contributors. Search in Pontoon or Transvision for these names and revert them to English.

Mozilla.org

The recently added new pages contain marketing languages to promote all the Firefox products. Localize them and start spreading the words on social media and other platforms. The deadline is indicative.

What’s new or coming up in SuMo

Newly published localizer facing documentation

The Firefox marketing guides are living documents and will be updated as needed.

Events

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

July 04, 2019 03:32 PM

May 23, 2019

Mozilla L10n Blog

L10n report: May edition

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.

Welcome!

New localizers

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New community/locales added

New content and projects

What’s new or coming up in Firefox desktop

Firefox 68 has officially entered Beta. The deadline to ship localization updates into this version is June 25. It’s important to remember that 68 is going to be an ESR version too: if your localization is incomplete on Jun 26, or contains errors, it won’t be possible to fix them later on for ESR.

A lot of content has landed in Firefox 68 towards the end of the cycle. In particular, make sure to test the new stub installer in the coming weeks, and the redesigned about:welcome experience. Detailed instructions are available in this thread on dev-l10n. You should also check out this post on how to localize the new “Join Firefox” message.

Partially related to Firefox Desktop: Facebook Container is quickly approaching version 2.0, adding several informative panels to the initial bare UI.

What’s new or coming up in mobile

As promised, more new and exciting things are happening in mobile land since our last report.

In fact, we have recently enabled two new projects in Pontoon, since we are opening up localization of a new password management product for both Android and iOS: Lockwise for Android (strings are located inside the locale folders, with a path starting by mozilla-mobile/lockwise-android/) and Lockwise for iOS – both formerly known as “Lockbox”. Ideal deadline for localizing and testing these projects is May 27th. As for previously enabled mobile projects, we are only exposing these strings to a subset of locales for now. We’ll add more locales as we get a handle on this first batch.

For Fenix and android-components strings, the current deadline for localizing and testing is still June 13th.

What’s new or coming up in web projects

Version 2 of the Firefox Monitor website is launching in the coming days. It’s a complete redesign, that will allow users to sign up with their Firefox Account, and monitor multiple emails easily.

Firefox Accounts: many strings were added in the recent feature updates. Please check Pontoon for the deadline. There might be more strings to be added before the weekend. The team will push codes more regularly to include as much localized content as possible on production before the launch of the new feature.

Mozilla.org added and updated four files in the past week: firefox/accounts-2019.lang, firefox/new/trailhead.lang, firefox/whatsnew_67.0.5.lang, and mozorg/newsletters.lang. Follow the deadline and prioritize against other requests.

Events

Friends of the Lion

Image by Elio Qoshi

Know someone in your l10n community who’s been doing a great job and should appear here? Contact on of the l10n-drivers and we’ll make sure they get a shout-out (see list at the bottom)!

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

May 23, 2019 06:04 AM

May 02, 2019

Axel Hecht

Migrate to Fluent

Introduction

A couple of weeks ago the Localization Team at Mozilla released the Fluent Syntax specification. As mentioned in our announcement, we already have over 3000 Fluent strings in Firefox. You might wonder how we introduced Fluent to a running project. In this post I’ll detail on how the design of Fluent plays into that effort, and how we pulled it off.

Fluent’s Design for Simplicity

Fluent abstracts away the complexities of human languages from programmers. At the same time, Fluent makes easy things easy for localizers, while making complex things possible.

When you migrate a project to Fluent, you build on both of those design principles. You will simplify your code, and move the string choices from your program into the Fluent files. Only then you’ll expose Fluent to localizers to actually take advantage of the capabilities of Fluent, and to perfect the localizations of your project.

Fluent’s Layered Design

When building runtime implementations, we created several layers to tightly own particular tasks.

  1. Fluent source files are parsed into Resources.
  2. Multiple resources are aggregated in Bundles, which expose APIs to resolve single strings. Message and Term references resolve inside Bundles, but not necessarily inside Resources. A Bundle is associated with a single language, as well as fallback languages for i18n libraries.
  3. Language negotiation and language fallback happen in the Localization level. Here you’d implement that someone looking for Frisian would get a Frisian string. If that’s missing or has a runtime problem, you might want to try Dutch, and then English.
  4. Bindings use the Localization API, and integrate it into the development stack. They marshal data models from the programming language into Fluent data models like strings, numbers, and dates. Declarative bindings also apply the localizations to the rendered UI.

Invest in Bindings

Bindings integrate Fluent into your development workflow. For Firefox, we focused on bindings to generate localized DOM. We also have bindings for React. These bindings determine how fluent Fluent feels to developers, but also how much Fluent can help with handling the localized return values. To give an example, integrating Fluent into Android app development would probably focus on a LayoutInflator. In the bindings we use at Mozilla, we decided to localize as close to the actual display of the strings as possible.

If you have declarative UI generation, you want to look into a declarative binding for Fluent. If your UI is generated programmatically, you want a programmatic binding.

The Localization classes also integrate IO into your application runtime, and making the right choices here has strong impact on performance characteristics. Not just on speed, but also the question of showing untranslated strings shortly.

Migrate your Code

Migrating your code will often be a trivial change from one API to another. Most of your code will get a string and show it, after all. You might convert several different APIs into just one in Fluent, in particular dedicated plural APIs will go away.

You will also move platform-specific terminology into the localization side, removing conditional code. You should also be able to stop stitching several localized strings together in your application logic.

As we’ll go through the process here, I’ll show an example of a sentence with a link. The project wants to be really sure the link isn’t broken, so it’s not exposed to localizers at all. This is shortened from an actual example in Firefox, where we link to our privacy policy. We’ll convert to DOM overlays, to separate localizable and non-localizable aspects of the DOM in Fluent. Let’s just look at the HTML code snippet now, and look at the localizations later.

Before:

<li>&msg-start;<a href="https://example.com">&msg-middle;</a>&msg-end;</li>

After:

<li data-l10n-id="msg"><a href="https://example.com" data-l10n-name="msg-link"></a></li>

Migrate your Localizations

Last but not least, we’ll want to migrate the localizations. While migrating code is work, losing all your existing localizations is just outright a bad idea.

For our work on Firefox, we use a Python package named fluent.migrations. It’s building on top of the fluent.syntax package, and programmatically creates Fluent files from existing localizations.

It allows you to copy and paste existing localizations into a Fluent string for the most simple cases. It also concats several strings into a single result, which you used to do in your code. For these very simple cases, it even uses Fluent syntax, with specialized global functions to copy strings.

Example:

msg = {COPY(from_path,"msg-start")}<a data-l10n-name="msg-link">{COPY(from_path,"msg-middle")}</a>{COPY(from_path,"msg-end")}

Then there are a bit more complicated tasks, notably involving variable references. Fluent only supports its built-in variable placement, so you need to migrate away from printf and friends. That involves firstly normalizing the various ways that a printf parameter can be formatted and placed, and then the code can do a simple replacement of the text like %2$S with a Fluent variable reference like {user-name}.

We also have logic to read our Mozilla-specific plural logic from legacy files, and to write them out as select-expressions in Fluent, with a variant for each plural form.

These transforms are implemented as pseudo nodes in a template AST, which is then evaluated against the legacy translations and creates an actual AST, which can then be serialized.

Concluding our example, before:

<ENTITY msg-start "This is a link to an ">
<ENTITY msg-middle "example">
<ENTITY msg-end ".">

After:

msg = This is a link to an <a data-l10n-name="msg-link">example</a> site.

Find out more about this package and its capabilities in the documentation.

Given that we’re OpenSource, we also want to carry over attribution. Thus our code not only migrates all the data, but also splits the migration into individual commits, one for each author of the migrated translations.

Once the baseline is migrated, localizers can dive in and improve. They can then start using parameterized Terms to adjust grammar, for example. Or add a plural form where English didn’t need one. Or introduce a platform-specific terminology that only exists in their language.

May 02, 2019 08:24 AM

April 19, 2019

Mozilla L10n Blog

L10n report: April edition

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.

Welcome!

New localizers

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New content and projects

What’s new or coming up in Firefox desktop

The deadline to ship localization updates in Firefox 67 is quickly approaching (April 30). Firefox 68 is going to be an ESR version, so it’s particularly important to ship the best localization possible. The deadline for that will be June 25.

The migration to Fluent is progressing steadily, and we are approaching two important milestones:

What’s new or coming up in mobile

Lot’s of things have been happening on the mobile front, and much more is going to follow shortly.

One of the first things we’d like to call out if that Fenix browser strings have arrived for localization! While work has been opened up to only a small subset of locales, you can expect us to add more progressively, quite soon. More details around this can be found here and here.

We’ve also exposed strings for Firefox Reality, Mozilla’s mixed-reality browser! Also open to only a subset of locales, we expect to be able to add more locales once the in-app locale switcher is in place. Read more about this here.

There are more new and exciting projects coming up in the next few weeks, so as usual, stay tuned to the Dev.l10n mailing list for more announcements!

Concerning existing projects: Firefox iOS v17 l10n cycle is going to start within the next days, so keep an eye out on your Pontoon folder.

And concerning Fennec, just like for Firefox desktop, the deadline to ship localization updates in Firefox 67 is quickly approaching (April 30). Please read the section above for more details.

What’s new or coming up in web projects

Mozilla.org

What’s new or coming up in SuMo

What’s new or coming up in Fluent

Fluent Syntax 1.0 has been published! The syntax is now stable. Thanks to everyone who shared their feedback about Fluent in the past; you have made Fluent better for everyone. We published a blog post on Mozilla Hacks with more details about this release and about Fluent in general.

Fluent is already used in over 3000 messages in Firefox, as well as in Firefox Send and Common Voice. If you localize these projects, chances are you already localized Fluent messages. Thanks to the efforts of Matjaž and Adrian, Fluent is already well-supported in Pontoon. We continue to improve the Fluent experience in Pontoon and we’re open to your feedback about how to make it best-in-class.

You can learn more about the Fluent Syntax on the project’s website, through the Syntax Guide, and in the Mozilla localizer documentation. If you want to quickly see it in action, try the Fluent Playground—an online editor with shareable Fluent snippets.

Events

Friends of the Lion

Know someone in your l10n community who’s been doing a great job and should appear here? Contact on of the l10n-drivers and we’ll make sure they get a shout-out (see list at the bottom)!

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

April 19, 2019 01:17 PM

April 11, 2019

Mozilla L10n Blog

Implementing Fluent in a localization tool

In order to produce natural sounding translations, Fluent syntax supports gender, plurals, conjugations, and virtually any other grammatical category. The syntax is designed to be simple to read, but translators without developer background might find more complex concepts harder to deal with.

That’s why we designed a Fluent-specific user interface in Pontoon, which unleashes Fluent powers to localizers who aren’t coders. Any other general purpose Translation Management System (TMS) with support for popular localization formats can follow the example. Let’s have a closer look at Fluent implementation in Pontoon.

Storing Fluent strings in the DB

We store Fluent translations in the Translation table differently compared to other file formats.

In the string column we usually only store the translatable content, which is sufficient for representing the translation across the application. For example, string hello = Hello, world! in the .properties file format is stored as Hello, world! in Translation.string. In Fluent, we store the entire string: hello = Hello, world!.

The main reason for storing full Fluent strings are attributes, which can be present in Fluent Messages and Terms in addition to their values. Having multiple localizable values stored together allows us to build advanced UIs like the ones we use for access keys (see below).

The alternative to storing the serialized string is to store its AST. At the time of implementing Fluent support in Pontoon, the AST wasn’t as stable as the syntax, but today you should be fine with using either of these approaches.

Different presentation formats

Due to their potential complexity, Fluent strings can be presented in 4 different ways in Pontoon:

  1. In simplified form: used in string list, History tab and various other places across Pontoon, it represents the string as it appears to the end-user in the application. We generate it using FluentSerializer.serializeExpression(). For example, hello = Hello, world! would appear simply as Hello, world!.
  2. In read-only form: used to represent the source string.
  3. In editable form: used to represent the translation in the editor.
  4. As source: used to represent the translation in the source editor.
Presentation formats

Where are different presentation formats used.
You can access the source view by clicking on the FTL button.

Example walk-through

The following is a list of various Fluent strings and their appearances in a Pontoon translation interface with source string panel on top and translation editor below. In the first batch are the strings using the existing Pontoon UI, shared with other file formats.

Simple strings
Simple strings

title = About Localization

Multiline strings
Multiline strings

feedbackUninstallCopy =
    Your participation in Firefox Test Pilot means
    a lot! Please check out our other experiments,
    and stay tuned for more to come!

Strings with a single attribute
Strings with a single attribute

emailOptInInput =
    .placeholder = email goes here :)

Next up are Fluent strings, which have attributes in addition to the value or multiple attributes. A separate text input is available for each of them.

Strings with a value and attributes
Strings with a value and an attribute

shotIndexNoExpirationSymbol = ∞
    .title = This shot does not expire

Since Fluent lets you combine labels and access keys within the same string, we designed a dedicated UI that lists all the allowed access keys as you translate the label. You can also type in a custom key if none of the candidates meets your criteria.

Access keys
Access keys

file-menu =
    .label = File
    .accesskey = F

Terms are similar to regular messages but they can only be used as references in other messages. Hence, they are best used to define vocabulary and glossary items which can be used consistently across the localization of the entire product. Terms can have multiple variants, and Pontoon makes it easy to add/remove them.

Terms
Terms

# Translated string
-brandShortName = { $case ->
    [nominative] Firefox Račun
   *[genitive] Firefox Računa
}

Selectors are a powerful feature of Fluent. They are used when there’s a need for multiple variants of the string based on an external variable. In the case case, PLATFORM().

Selectors
Selectors

platform = { PLATFORM() ->
    [win] Options
   *[other] Preferences
}

A common use case of selectors are plurals. When you translate a pluralized source string, Pontoon renders empty CLDR plural categories used in the target locale, each accompanied by an example number.

Plurals
Plurals

delete-all-message = { $num ->
    [one] Delete this download?
   *[other] Delete { $num } downloads?
}

Selectors can also be used in attributes. Pontoon hides most of the complexity.

Selectors in attributes
Selectors in attributes

download-choose-folder =
    .label = { PLATFORM() ->
        [macos] Choose…
       *[other] Browse…
    }
    .accesskey = { PLATFORM() ->
        [macos] e
       *[other] o
    }

If a value or an attribute contains multiple selectors, Pontoon indents them for better readability.

Strings with multiple selectors
Strings with multiple selectors

selector-multi = There { $num ->
    [one] is one email
   *[other] are many emails
} for { $gender ->
   *[masculine] him
    [feminine] her
}

Strings with nested selectors are not supported in Fluent editor, in which case Pontoon falls back to the source editor. The source editor is always available, and you can switch to it by clicking on the FTL button.

Unsupported strings
Unsupported strings

Next steps

The current state of the Fluent UI in Pontoon allows us to use Fluent to localize Firefox and various other projects. We don’t want to stop here, though. Instead, we’re looking to improve the Fluent experience further and make it the best among available localization formats. You can track the list of Fluent-related Pontoon bugs in Bugzilla. Some of the highlights include:

April 11, 2019 12:42 PM

April 02, 2019

Mozilla L10n Blog

Changing the Language of Firefox Directly From the Browser

Language Settings

In Firefox there are two main user facing settings related to languages:

The difference between the two is not as intuitive as it might seem. A lot of users change the web content settings, and expect the user interface to change.

The Legacy Chaos

While the preferences for web content have been exposed in Firefox since its first versions, changing the language used for the user interface has always been challenging. Here’s the painful journey users had to face until a few months ago:

The alternative is to install a build of Firefox already localized in your preferred language. But, once again, they’re not so easy to find. Imagine you work in a corporate environment that provides you with an operating system in English (en-US). You search the Web for “Firefox download”, and automatically end up on this download page, which doesn’t provide information on the language you’re about to download. You need to pay a lot of attention and notice the link to other languages.

If you already installed Firefox in the wrong language, you need to uninstall it, find the installer in the correct language, and reinstall it. As part of the uninstall process on Windows, we ask users to volunteer for a quick survey to explain why they’re uninstalling the browser, and the amount of them saying something along the line of “wrong language” or “need to reinstall in the right language” is staggering, especially considering this is an optional comment within an optional survey. It’s a clear signal, if one was ever needed, that things need to improve.

Everything Changes with Firefox 65

Fast forward to Firefox 65:

We introduced a new Language section. Directly from the General pane it’s now possible to switch between languages already available in Firefox, removing the need for manually setting preferences in about:config. What if the language is not available? Then you can simply Search for more languages… from the dropdown menu.

Add your preferred language to the list (French in this case).

And restart the browser to have the interface localized in French. Notice how the message is displayed in both languages, to provide users with another hint to the user that they selected the right language.

If you’re curious, you can see a diagram of the complete user interaction here.

A lot happens under the hood for this brief interaction:

This feature is enabled by default in Beta and Release versions of Firefox. Language packs are not reliable on Nightly, given that strings change frequently, and a language still considered compatible but incomplete could lead to a completely broken browser (condition known as “yellow screen of death“, where the XUL breaks due to missing DTD entities).

What’s Next

First of all, there are still a few bugs to fix (you can find a list in the dependencies of the tracking bug). Sadly, there are still several places in the code that assume the language will never change, and cache the translated content too aggressively.

The path forward has yet to be defined. Completing the migration to Fluent would drastically improve the user experience:

There are also areas of the browser that are not covered by language packs, and would need to be rewritten (e.g. the profile manager). For these, the language used always remains the one packaged in the build.

The user experience could also be improved. For example, can we make selecting the language part of a multiplatform onboarding experience? There are a lot of hints that we could take from the host operating system, and prompt the user about installing and selecting a different language. What if the user browses a lot of German content, but he’s using the browser in English? Should we suggest them that it’s possible to switch language?

With Firefox 66 we’re also starting to collect Telemetry data about internationalization settings – take a look at the table at the bottom of about:support – to understand more about our users, and how these changes in Preferences impact language distribution and possibly retention.

For once, Firefox is well ahead of the competition. For example, for Chrome it’s only possible to change language on Windows and Chromebook, while Safari only uses the language of your macOS.

This is the result of an intense cross-team effort. Special thanks to Zibi Braniecki for the initial idea and push, and all the work done under the hood to improve Firefox internationalization infrastructure, Emanuela Damiani for UX, and Mark Striemer for the implementation.

April 02, 2019 06:33 AM

March 21, 2019

Mozilla L10n Blog

L10n report: March edition

New content and projects

What’s new or coming up in Firefox desktop

Schedule and important dates

Firefox 66 has been released on March 19, which means:

The deadline to ship updates for Beta will be on April 30. Also don’t forget that Firefox 68 is going to be the next ESR version: ideally you should be localizing it early in Nightly, in order to have a good amount of time for testing before it reaches the release channel.

Removing unmaintained locales

This is not an action that we take lightly, because it’s demoralizing for the Community and potentially confusing for users, but in some cases we have to remove locales from Firefox builds. As outlined in the document, we try our best to revive the localization effort, and only act when it’s clear that we can’t solve the problem in other ways.

In Firefox 68 we’re going to remove the following locales: Assamese (as), South-African English (en-ZA), Maithili (mai), Malayalam (ml), Odia (or).

We’re also working with the Bengali community to unify two locales – Bengali India (bn-IN) and Bengali Banglashed (bn-BD) – under a single locale (bn), to optimize the Community resources we have.

Firefox Monitor

The add-on for Firefox Monitor is now localized as part of the main Firefox projects. If you want to test it:

What’s new or coming up in mobile

Just like for Firefox Desktop, the deadline to ship updates for Fennec Beta will be on April 30. Read the previous section of this report for more details surrounding that.

A notable Android update this month (that we’ve just announced on the dev-l10n mailing list – please consider following if it’s not yet the case) is that we’ve exposed on Pontoon the new Android-Components strings as part of the new Android-l10n project, to a small subset of locales.

Fenix browser strings are right around the corner as well, and will be exposed very soon in that same project, so stay tuned. Read up here for more details on all this.

On Firefox iOS side, we’re still working hard on shipping the upcoming version, which will be v16. Deadline for localization was today (March 21st), and with this new version we are adding one new locale: Vietnamese! Congrats to the team for shipping their first localized version of Firefox iOS!

What’s new or coming up in web projects

AMO and Facebook Container extension

Mozilla is partnering with the European Union to promote its Facebook Container extension in advance of the upcoming EU elections. We have translated the listing for the extension on addons.mozilla.org into 24 languages primarily used within the EU, and we could use your help localizing the user interface for addons.mozilla.org so people can have a more complete experience when downloading the extension. AMO frontend and server are two huge projects. If your locale has a lot to catch up, you can focus on these top priority strings the team has identified (note there are two tabs). You can search for them in the AMO Frontend project in Pontoon.

In order to promote the extension in 24 languages, we need to enable AMO server and AMO Frontend in all the languages, including Maltese, of which we don’t have a community. We also added a few languages out of product requirement without communities’ agreement.  These languages are on the “read-only” locale list. They are Croatian, Estonian, Latvian, and Lithuanian for AMO Frontend, and Estonian and Latvian for AMO Server. If any of these communities are interested in localizing at least the high priority strings, please email the l10n-drivers so we can change the language setting.

Mozilla.org

There are a few updates coming soon. To prioritize, make sure to focus on shared files first (main.lang, download_button.lang), then the rest by star priority rating, or by deadline if applicable. You may see a few of the same strings appearing in several files. We usually leverage existing translations into a brand new file, but less so for updated file. In the latter case, please rely on Pontoon’s `Machinery` feature to leverage from your previous work.

Common Voice

Many new contributors joined the Mozilla localization communities through this project and are only interested in this project. Though there is an existing community that has been localizing other projects, the new contributors are new to localization, to Pontoon, to Mozilla localization process. They need your help with onboarding. Many have contributed to the project and are waiting for constructive feedback. Locale managers, please check the Common Voice project to see if there are strings waiting to be reviewed in your locale. Try to arrange resources to provide feedback in a timely manner. Based on the quality of the new contributors’ work and their interest, you can grant them broader permission at project level.

What’s new or coming up in Foundation projects

A very quick update on the misinformation campaign — the scorecard mentioned last month won’t be released, due to external changes. The good news is that a lot of the work done by the team is being reused and multiple campaigns will be launched instead. Details are evolving quickly, so there’s not much to share yet. We will keep you posted!

What’s new or coming up in Pontoon

Translate.Next. Soon we’ll begin testing of the rewritten translation interface of Pontoon. The look & feel will largely remain the same, but the codebase will be completely different, allowing us to fulfill user requests in a more timely manner. Stay tuned for more updates in the usual l10n channels!

Improving experience for 3rd party installations. While used internally at Mozilla, Pontoon is a general purpose TMS with good support for popular localization file formats, ready to localize a variety of open source projects, apps or websites. Vishal started improving experience for 3rd party deployments by making Pontoon homepage customizable instead of hardcoding the Mozilla-specific content used on pontoon.mozilla.org. The path to setting up a first project for localization is now also more obvious.

 

Under the hood changes. Thanks to Jotes and Aniruddha, our Python test coverage has  improved. On top of that, Jotes started making first steps towards migrating our codebase to Python3.

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

March 21, 2019 02:47 PM

February 21, 2019

Mozilla L10n Blog

L10n report: February edition

Welcome!

New localizers

The following contributors came to us through the Common Voice project.

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New community/locales added

New content and projects

What’s new or coming up in Firefox desktop

This week we’re going to reach an important milestone for Fluent in Firefox, having more Fluent strings than DTDs in mozilla-central (currently 2466 vs 2489). There are already 5 patches in review to migrate more elements to Fluent, thanks to the work of the MSU Capstone students: Page Info window, contextual menu for tabs, print dialogs, about:privatebrowsing, Password Manager dialog.

Here are a few important dates for the current release cycles:

In terms of content, the priority currently remains on the profile-per-install feature already mentioned in the previous l10n report, and on the dev-l10n mailing list.

What’s new or coming up in mobile

This has been a rather quiet month in regards to mobile localization updates.

Teams are mostly heads-down working on kicking off the Fenix browser project.

In the meantime, other mobile apps are following their usual timelines and schedule –  so there is nothing much to call out this month.

Stay tuned for the next report, as we’ll have a few things in the pipeline to call out for sure!

What’s new or coming up in web projects

Mozilla.org

We’ve added a new page ahead of the Firefox 66 release. Check in Pontoon and look for firefox/whatsnew_66.lang. To be part of the release, make sure to complete it by March 6. The demo URL is not ready at the moment. We will update you as soon as it becomes available.

A small but an important update is in the privacy/index.lang file. The change is urgent so please localize the string as soon as possible.

Have you taken a look of the newly designed navigation bar? It was recently rolled out with quite a bit of content to localize. Make it a high priority if it is not localized yet.

Common Voice

The team is super excited to launch the sentence collection tool! Though in Beta, it is fully functional. Moving forward, the site will be the place to submit, review and validate sentences in a more organized way and it is a lot easier for everyone, especially those who are not technical. Be sure to read the How To guide to make full use of the features. We want to thank all the key contributors who helped make the tool a reality.

Legal documents

Common Voice: The Privacy Notice and the Legal Terms have been updated in English. Only a select few languages are updated accordingly. These are the languages that have reached the threshold of collecting a minimum of 5000 sentences. If your community has  the bandwidth, feel free to review and make necessary suggestions. All these suggestions are subject to peer review before the corrections are published. These are the languages that are recently updated: Breton, Catalan, Chuvash, Dutch, Esperanto, German, French, Hakha Chin, Irish, Italian, Kabyle, Kyrgyz, Slovenian, Tatar, Traditional Chinese, Turkish, Welsh.

Firefox Lite: We’ve added Traditional Chinese and Vietnamese to the Privacy Notice. Feel free to review the document and make necessary changes.

What’s new or coming up in Foundation projects

The foundation’s impact goal — Better machine decision making — now has its public wiki page with a lot of resources explaining the Foundation’s goals and activities for 2019 and beyond. If you want to learn more about what MoFo is up to, this is a great way to dive in!

Fundraising

The fundraising team is starting to plan some mini-campaigns linked to specific events (the Internet Health Report publication, Fellowships, MozFest, and the traditional end-of-year fundraising) with the goal of explaining that Mozilla does much more than a browser and providing potential donors with a better understanding of the Foundation’s work.
We mentioned the new receipts in the previous L10N Report, those are still coming, they just needed further adjustments and another round of review from the Legal team. The team wants to get this right to have future-proof donation receipts.

Advocacy

The EU misinformation campaign has started! The survey mentioned last month went out, and on February 11th, the team sent an open letter to Facebook (simultaneously launched in English, French & German) asking for more transparency on political ads ahead of the EU elections. This letter was also signed by 38 partners including Access Now, Greenpeace and Reporters Without Borders.

Facebook responded in just a few hours, preventing us from publishing the open letter in more languages, but thanks to the dedication of localizers, the simultaneous launch in multiple languages has more than doubled the public engagement: while the team has sent more emails in English, engagement in the campaign in terms of clicks, open letter signatures and post-signing donations came primarily from localized emails in French and German! Mozilla has since responded to the announcement.

Next steps will be an opportunity to involve even more locales and will include launching a scorecard and an election bundle. Rooted in the principles outlined in the European Commission’s Code of Practice on Disinformation, the scorecard will compare how major social platforms are performing as they take steps to combat dis/misinformation.

What’s new or coming up in SuMo

There have been some important changes in Mozilla staff since the last report.

We need your help to review the following articles:

Want to follow the Firefox 66 modified articles to be published in the SUMO Discourse in the coming weeks?  Please subscribe to the tag.

What’s new or coming up in Pontoon

At the end of last year we held a community design sprint with aim of improving the review process in Pontoon. The proposed changes were mostly focused around one of the top requested features of Pontoon – translation comments.

The following product specification is a result of the design sprint. It defines the problem we’re solving, lists measurable goals we’d like to achieve, outlines the proposed solution and provides a rough timeline.

It’s a short, 7 minute read. Please have a look at it, or at least skim through the screenshot tour. As you’ll see, changes to the translate view are pretty substantial, so we’d like to hear your opinion. Either on Discourse or in the spec.

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

February 21, 2019 06:40 PM

February 06, 2019

Mozilla L10n Blog

A New Year with New Goals for Mozilla Localization

 

We had a really ambitious and busy year in 2018! Thanks to the help of the global localization community as well as a number of cross-functional Mozilla staff, we were able to focus our efforts on improving the foundations of our localization program. These are some highlights of what we accomplished in 2018:

Rather than plan out our goals for the full year in 2019, we’ve been encouraged to take it a quarter at a time. That being said, there are a number of interesting themes that will pop up in 2019 as well as the continuation of work from 2018:

Standardize & Scale

There are still areas within our tool-chain as well as our processes that make it hard to scale localization to all of Mozilla. Over the course of 2018 we saw more and more l10n requests from internal teams that required customized processes. The good news here is that the organization as a whole wants to localize more and more content (that hasn’t been true in the past)!

While we’ve seen success in standardizing the processes for localizing product user interfaces, we’ve struggled to rein in the customizations for other types of content. In 2019, we’ll focus a lot of our energy on bringing more stability and consistency to localizers by standardizing localization processes according to specific content types. Once standardized, we’ll be able to scale to meet the the needs of these internal teams while keeping the amount of new content to translate in consistent volumes.

Mobilize South East Asian Locales

One of the primary focus areas for all of Mozilla this year is South East Asian markets. The Emerging Markets team in Taipei is focused on creating products for those markets that meet the needs of users there, building on the success of Screenshots Go and Firefox Lite. This year we’ll see more products coming to these markets and it will be more important than ever for us to know how to mobilize l10n communities in those regions in order to localize these exciting, new products.

New Technologies

Early this year we plan to hit a major milestone: Fluent 1.0! This is the culmination of over a decade’s worth of work and we couldn’t be more proud of this accomplishment. Fluent will continue to be implemented in Firefox as well as other Mozilla projects throughout 2019. We’re planning a roadmap for an ecosystem of tooling to support Fluent 1.0 as well as exploring how to build a thriving Fluent community.

Pontoon’s Translate view rewrite to React will be complete and we’ll be implementing features for a newly redesigned review process. Internationalizing the Pontoon Translate UI will be a priority, as well as addressing some long-requested feature updates, like terminology support as well as improved community and user profile metrics.

Train the Trainers

In 2018 we published clear descriptions of the responsibilities and expectations of localizers in specific community roles. These roles are mirror images of Pontoon roles, as Pontoon is the central hub for localization at Mozilla. In 2019, we plan to organize a handful of workshops in the latter half of the year to train Managers on how to be effective leaders in their communities and reliable extensions of the l10n-drivers team. We would like to record at least one of these and make the workshop training available to everyone through the localizer documentation (or some other accessible place).

We aim to report on the progress of these themes throughout the year in quarterly reports. In each report, we’ll share the outcomes of the objectives of one quarter and describe the objectives for the next quarter. In Q1 of 2019 (January – March), the l10n-drivers will:

As always, if you have questions about any of these objectives or themes for 2019, please reach out to an l10n-driver, we’d be very happy to chat.

February 06, 2019 09:35 PM

January 17, 2019

Mozilla L10n Blog

L10n report: January edition

Welcome!

New localizers

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New community/locales added

New content and projects

What’s new or coming up in Firefox desktop

The localization cycle for Firefox 66 in Nightly is approaching its end, and Tuesday (Jan 15) was the last day to get changes into Firefox 65 before it moves to release (Jan 29). These are the key dates for the next cycle:

As of January, localization of the Pocket add-on has moved back into the Firefox main project. That’s a positive change for localization, since it gives us a clearer schedule for updates, while before they were complex and sparse. All existing translations from the stand-alone process were imported into Mercurial repositories (and Pontoon).

In terms of prioritization, there are a couple of features to keep an eye on:

What’s new or coming up in Test Pilot

As explained in this blog post, Test Pilot is reaching its end of life. The website localization has been updated in Pontoon to include messages around this change, while other experiments (Send, Monitor) will continue to exist as stand-alone projects. Screenshots is also going to see changes in the upcoming days, mostly on the server side of the project.

What’s new or coming up in mobile

Just like for Firefox desktop, the last day to get in localizations for Fennec 65 was Tuesday, Jan 15. Please see the desktop section above for more details.

Firefox iOS v15 localization deadline was Friday, January 11. The app should be released to everyone by Jan 29th, after a phased roll-out. This time around we’ve added seven new locales: Angika, Burmese, Corsican, Javanese, Nepali, Norwegian Bokmål and Sundanese. This means that we’re currently shipping 87 locales out of the 88 that are being localized – which is twice as more than when we first shipped the app. Congrats to all the voluntary localizers involved in this effort over the years!

And stay tuned for an update on the upcoming v16 l10n timeline soon.

We’re also still working with Lockbox Android team in order to get the project plugged in to Pontoon, and you can expect to see something come up in the next couple of weeks.

Firefox Reality project is going to be available and open for localization very soon too. We’re working out the specifics right now, and the timeline will be shared very soon and once everything is ironed out.

What’s new or coming up in web projects

Mozilla.org has a few updates.

What’s new or coming up in Foundation projects

Mozilla’s big end-of-year push for donations has passed, and thanks in no small part to your efforts, the Foundation’s financial situation is in a much better shape for this year to pick up the fight where they left it before the break. Thank you all for your help!

In these first days of 2019, the fundraising team takes the opportunity of the quiet time to modernize the donation receipts with a better email sent to donors and migrate the receipts to the same infrastructure used to send Mozilla & Firefox newsletters. Content for the new receipts should be exposed in the Fundraising project by the end of the month for the 10-15 locales with the most donations in 2018.

The Advocacy team is still working on the misinfo campaign in Europe, with a first survey coming up to be sent to the people subscribed to the Mozilla newsletter, to get a flavor of where opinion lies with their attitudes to misinformation at the moment. Next steps will include launching a campaign about political ads ahead of the EU elections then promote anti-disinformation tools. Let’s do this!

What’s new or coming up in Support

What’s new or coming up in Pontoon

We re-launched the ability to delete translations. First you need to reject a translation, and then click on the trash can icon, which only appears next to rejected translations. The delete functionality has been replaced by the reject functionality, but over time it became obvious there are various use cases for both features to co-exist. See bug 1397377 for more details about why we first removed and then restored this feature.

Events

Friends of the Lion

Image by Elio Qoshi

 

Know someone in your l10n community who’s been doing a great job and should appear here? Contact on of the l10n-drivers and we’ll make sure they get a shout-out (see list at the bottom)!

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

January 17, 2019 08:08 AM

December 14, 2018

Mozilla L10n Blog

L10n report: December edition

Hi everyone and welcome to the December 2018 Mozilla l10n report!

Before getting into the individual updates, I wanted to call out that the Mozilla All Hands was held last week in Orlando, FL. For our part, we made progress on conversations with different marketing groups, mozilla.org engineers, and Open Innovation about standardizing the l10n process for each of their types of content requiring translation. We also had a few cross-organization discussions about Fluent in Firefox and the Multilingual Firefox project. Plans for 2019, on an organization level, are still being finalized and are too early to share at the moment, but we look forward to opportunities to share those plans once they’re ready.

Thank you for a full year of donating your time to localize Mozilla projects. We’re incredibly grateful to get to work with you and look forward to accomplishing more together next year!

Welcome!

New localizers

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New content and projects

What’s new or coming up in Firefox desktop

Firefox 64 has been officially released on December 11. As a localizer, it’s important to  remember that there’s a strict deadline to ship updates in the next official version of Firefox, and that’s about 2 weeks before the release date (Nov 27 for Firefox 64). The deadline to ship updates to translations in Firefox 65 will be January 15.

In general, the best approach is to localize Nightly periodically, and use Nightly in your daily browsing to test your work (it’s updated twice a day). If you can’t, then targeting the very beginning of the beta cycle is a good alternative, to leave a few weeks for testing on Beta, and get as many eyes as possible on the localized version.

As for Firefox 65 and 66, while the migration to Fluent proceeds, the main focus – and source of strings – still remains testing and improving tracking protection features and security error pages.

Firefox 65 will include an exciting and brand new feature for multilingual users, but we’ll talk about it in a dedicated blog post with all the details.

What’s new or coming up in Test Pilot

Be on the lookout for an important announcement about Test Pilot in the coming days.

 

What’s new or coming up in mobile

Just like for Firefox desktop, please keep an eye out for getting your localizations in before the deadline for the Firefox for Android 65 version (next up is January 15). See the section above for more details.

Firefox Reality v1.1 is now localized in a small subset of languages. We’ll be expanding to more locales for the upcoming release (timeline TBD). Stay tuned!

We have exciting news about Lockbox, your preferred password manager: it’s coming to Android very soon too! We will be getting strings for localization over the course of January. Stay tuned for an update about this early in 2019. And the iOS version won’t be very far behind in terms of l10n 🙂

There are also some imminent changes coming to Pontoon and native strings.xml support. As in: it will exist \o/ Please keep an eye out as we’ll be announcing these changes in detail very soon as well.

 

What’s new or coming up in web projects

The Community Participation Guidelines (or CPG) have been recently updated. Included in the updates are ways to report intolerable behaviors. These two pages are localized in a few languages, and is done through an agency and funded by the D&I team. If you feel the need to have these two pages localized in your languages in order to better understand the guidelines, send a request through Pontoon.

Common Voice has turned on voice collection for 16 languages after each of the languages reached the major milestones of completing the website localization and collecting 5000 sentences! This number is continuing to grow because of your support!

Mozilla.org: if you and the community have not had the bandwidth to work on this project due to competing demand from projects in the last few months, December, usually a slower month, might be the time to do some catch-up: translate and review the suggestions. The landing page for a few locales is now redirected to English. Focus first on this and other core pages with 5-star rating. If you need help to prioritize, let l10n-drivers know.

 

What’s new or coming up in Foundation projects

The Mozilla Foundation has an impact goal for 2019! “Better Machine Decision Making”. More specifically, the draft goal description is that “We all understand when machines are making decisions for us — and about us. We have a way to work alongside them and correct them if they make mistakes.”

60% of the resources of the foundation will be dedicated towards this goal next year, so you can expect it to show up in multiple initiatives. How it shows up in the foundation work will evolve, and it is intended to be broad for now. For Advocacy, fighting misinformation in Europe, as well as asking Facebook for more transparency will be key. And a few languages will be key to this work.

On this topic, those of you who read the l10n report last month may have noticed that the Misinfo test campaign didn’t happen early November as expected. The team wasn’t confident enough about the early campaign ideas, so it was decided to cancel them in favor of working directly towards the first big campaigns of 2019.

Quoting an extract of the latest fundraising email to give you an overview of the incoming campaign around the EU elections, the plan is to:

Speaking about fundraising, it’s crunch time! The last two emails of the year should be exposed by early next week, and this will allow the team to raise money until the very end of the year! Thanks for all the efforts so far!

 

What’s new or coming up in SuMo

Matching Firefox Desktop locales. With the upcoming changes to the amount of localization projects in Pontoon in 2019, we are adding all the currently served Firefox Desktop locales as available ones for support.mozilla.org’s user interface, as serviced through Pontoon. Starting from 2019, they will also be available as article content locales for localization at http://support.mozilla.org/. To learn more about localizing the Support wiki, visit this page.

Rewriting contribution documentation for localization. Speaking of which, the documentation helping new localization contributors get started (and experienced contributors keep their skills fresh) will undergo an extensive rewrite in Q1 2019. If you are interesting in reviewing the new documentation before it goes live, contact Michał.

New content ready for localization [Firefox 64]. With the new release, a slew of articles has been updated and is ready for community localization:

 

What’s new or coming up in Pontoon

Extending TM support. Until recently, querying for strings longer than 255 characters in Pontoon’s Translation Memory didn’t work at all. While the portion of such strings isn’t too large, the longer the string, the more time can be saved if TM can be used. This limitation has now been dropped. That means Pontoon now shows perfect and fuzzy matches from Translation Memory for all strings, regardless of their length. Kudos to Jotes for the patch!

Request a language from project page. Your team page allows you to request new projects to be enabled for your locale. From now on you can make similar request from project pages. Let’s say you are on the Firefox Monitor Add-On page. Click on Request new language, pick a language and you’re to send a request to project managers. Thanks to Vishal for implementing this feature!

Native Support for Android l10n. We’ve landed support for String resources, an XML-based file format used for localizing Android applications. Most of the functionality is provided by the compare-locales library, which provides the strings.xml parser and serializer, as well as the quality checks. Native support for Android l10n infrastructure is a welcome addition for developers, who will no longer need to convert localization files to other file formats, e.g. Gettext PO.

Support for l10n project configuration files. Another step towards making developers’ lives easier is support for the so called project config. Until recently, Pontoon required project repositories to follow a particular directory structure in order to be able to detect localization files. That can be tedious in some scenarios and could require developers to change file structure during the during build process. By specifying file paths in project configuration files, which are now supported by Pontoon, projects can now use virtually any file structure and Pontoon will be able to support it.

Improving the review process. We’re hosting a community event in Paris this weekend, where we’ll design a new review process for community localization at Mozilla. One area we’d like to improve in particular is communication between reviewers and translators. We’ll spend a good amount of time brainstorming, sketching, prototyping and user testing. Stay tuned for more updates soon!

 

Events

Accomplishments

Localization impact by the numbers:

Friends of the Lion

Image by Elio Qoshi

Know someone in your l10n community who’s been doing a great job and should appear here? Contact on of the l10n-drivers and we’ll make sure they get a shout-out (see list at the bottom)!

Useful Links

Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

December 14, 2018 06:35 PM

August 07, 2018

Mitchell Baker

In Memoriam: Gervase Markham

Gerv was Mozilla’s first intern.  He arrived in the summer of 2001, when Mozilla staff was still AOL employees.  It was a shock that AOL had allocated an intern to the then-tiny Mozilla team, and we knew instantly that our amazingly effective volunteer in the UK would be our choice.

When Gerv arrived a few things about him jumped out immediately.  The first was a swollen, shiny, bright pink scar on the side of his neck.  He quickly volunteered that the scar was from a set of surgeries for his recently discovered cancer.  At the time Gerv was 20 or so, and had less than a 50% chance of reaching 35.  He was remarkably upbeat.

The second thing that immediately became clear was Gerv’s faith, which was the bedrock of his response to his cancer.  As a result the scar was a visual marker that led straight to a discussion of faith. This was the organizing principle of Gerv’s life, and nearly everything he did followed from his interpretation of how he should express his faith.

Eventually Gerv felt called to live his faith by publicly judging others in politely stated but damning terms.  His contributions to expanding the Mozilla community would eventually become shadowed by behaviors that made it more difficult for people to participate.  But in 2001 all of this was far in the future.

Gerv was a wildly active and effective contributor almost from the moment he chose Mozilla as his university-era open source project.  He started as a volunteer in January 2000, doing QA for early Gecko builds in return for plushies, including an early program called the Gecko BugAThon.  (With gratitude to the Internet Archive for its work archiving digital history and making it publicly available.)

Gerv had many roles over the years, from volunteer to mostly-volunteer to part-time, to full-time, and back again.  When he went back to student life to attend Bible College, he worked a few hours a week, and many more during breaks.  In 2009 or so, he became a full time employee and remained one until early 2018 when it became clear his cancer was entering a new and final stage.

Gerv’s work varied over the years.  After his start in QA, Gerv did trademark work, a ton of FLOSS licensing work, supported Thunderbird, supported Bugzilla, Certificate Authority work, policy work and set up the MOSS grant program, to name a few areas. Gerv had a remarkable ability to get things done.  In the early years, Gerv was also an active ambassador for Mozilla, and many Mozillians found their way into the project during this period because of Gerv.

Gerv’s work life was interspersed with a series of surgeries and radiation as new tumors appeared. Gerv would methodically inform everyone he would be away for a few weeks, and we would know he had some sort of major treatment coming up.

Gerv’s default approach was to see things in binary terms — yes or no, black or white, on or off, one or zero.  Over the years I worked with him to moderate this trait so that he could better appreciate nuance and the many “gray” areas on complex topics.  Gerv challenged me, infuriated me, impressed me, enraged me, surprised me.  He developed a greater ability to work with ambiguity, which impressed me.

Gerv’s faith did not have ambiguity at least none that I ever saw.  Gerv was crisp.  He had very precise views about marriage, sex, gender and related topics.  He was adamant that his interpretation was correct, and that his interpretation should be encoded into law.  These views made their way into the Mozilla environment.  They have been traumatic and damaging, both to individuals and to Mozilla overall.

The last time I saw Gerv was at FOSDEM, Feb 3 and 4.   I had seen Gerv only a few months before in December and I was shocked at the change in those few months.  Gerv must have been feeling quite poorly, since his announcement about preparing for the end was made on Feb 16.  In many ways, FOSDEM is a fitting final event for Gerv — free software, in the heart of Europe, where impassioned volunteer communities build FLOSS projects together.

To memorialize Gerv’s passing, it is fitting that we remember all of Gerv —  the full person, good and bad, the damage and trauma he caused, as well as his many positive contributions.   Any other view is sentimental.  We should be clear-eyed, acknowledge the problems, and appreciate the positive contributions.  Gerv came to Mozilla long before we were successful or had much to offer besides our goals and our open source foundations.  As Gerv put it, he’s gone home now, leaving untold memories around the FLOSS world.

August 07, 2018 06:19 PM

July 12, 2018

Axel Hecht

Localization, Translation, and Machines

TL;DR: Is there research bringing together Software Analysis and Machine Translation to yield Machine Localization of Software?

I’m Telling You, There Is No Word For ‘Yes’ Or ‘No’ In Irish

from Brendan Caldwell

The art of localizing a piece of software with a Yes button is to know what that button will do. This is an example of software UI that makes assumptions on language that hold for English, but might not for other languages. A more frequent example in both UI and languages that are affecting is piecing together text and UI controls:

In the localization tool, you’ll find each of those entries as individual strings. The localizer will recognize that they’re part of one flow, and will move fragments from the shared string to the drop-down as they need. Merely translating the individual segments is not going to be a proper localization of that piece of UI.

If we were to build a rule-based machine localization system, we’d find rules like

Now that’s rule-based, and it’d be tedious to maintain these rules. Neural Machine Translation (NMT) has all the buzz now, and Machine Learning in general. There is plenty of research that improves how NMT systems learn about the context of the sentence they’re translating. But that’s all text.

It’d be awesome if we could bring Software Analysis into the mix, and train NMT to localize software instead of translating fragments.

For Firefox, could one train on English and localized DOM? For Android’s XML layout, a similar approach could work? For projects with automated screenshots, could one train on those? Is there enough software out there to successfully train a neural network?

Do you know of existing research in this direction?

July 12, 2018 01:25 PM

September 16, 2017

Mitchell Baker

Busting the myth that net neutrality hampers investment

This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas.

I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers.

Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States.

The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population.

At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike.

Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use:


(Video courtesy: GSMA)

If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here.

You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it.

September 16, 2017 04:00 AM

August 18, 2017

Mitchell Baker

Resignation as co-chair of the Digital Economy Board of Advisors

For the past year and a half I have been serving as one of two co-chairs of the U.S. Commerce Department Digital Economy Board of Advisors. The Board was appointed in March 2016 by then-Secretary of Commerce Penny Pritzer to serve a two year term. On Thursday I sent the letter below to Secretary Ross.

Dear Secretary Ross,
I am resigning from my position as a member and co-chair of the Commerce Department’s Digital Economy Board of Advisors, effective immediately.
It is the responsibility of leaders to take action and lift up each and every American. Our leaders must unequivocally denounce bigotry, racism, sexism, hate, and violence.
The digital economy is fundamental to creating an economy that offers opportunity to all Americans. It has been an honor to serve as member and co-chair of this board and to work with the Commerce Department staff.
Sincerely,
Mitchell Baker
Executive Chairwoman
Mozilla

August 18, 2017 07:12 PM

April 28, 2017

Mitchell Baker

New Mozilla Foundation Board Members: Mohamed Nanabhay and Nicole Wong

Today, I’m thrilled to announce that Mohamed Nanabhay and Nicole Wong have joined the Mozilla Foundation Board of Directors.

Over the last few years, we’ve been working to expand the boards for both the Mozilla Foundation and the Mozilla Corporation. Our goals for the Foundation board roles were to grow Mozilla’s capacity to move our mission forward; expand the number and diversity of people on our boards, and; add specific skills in areas related to movement building and organizational excellence. Adding Mohamed and Nicole represents a significant move forward on these goals.

We met Mohamed about seven years ago through former board member and then Creative Commons CEO Joi Ito. Mohamed was at Al Jazeera at the time and hosted one of Mozilla’s first Open News fellows. Mohamed Nanabhay currently serves as the Deputy CEO of the Media Development Investment Fund (MDIF), which invests in independent media around the world providing the news, information and debate that people need to build free, thriving societies.

Nicole is an attorney specializing in Internet, media and intellectual property law. She served as President Obama’s deputy chief technology officer (CTO) and has also worked as the vice president and deputy general counsel at Google to arbitrate issues of censorship. Nicole has already been active in helping Mozilla set up a new fellows program gathering people who have worked in government on progressive tech policy. That program launches in June.

Talented and dedicated people are the key to building an Internet as a global public resource that is open and accessible to all. Nicole and Mohammad bring expertise, dedication and new perspectives to Mozilla. I am honored and proud to have them as our newest Board members.

Please join me in welcoming Mohamed and Nicole to the Board. You can read more about why Mohamed chose to join the Board here, and why Nicole joined us here.

Mitchell

April 28, 2017 08:29 PM

March 23, 2017

Axel Hecht

Can’t you graph that graph

I’m going to just recreate blame, he said. It’s going to be easy, he said.

We have a project to migrate the localization of Firefox to one repository for all channels, nick-named cross-channel, or x-channel in short. The plan is to create one repository that holds all the en-US strings we need for Firefox and friends on all channels. One repository to rule them all, if you wish. So you need to get the contents of mozilla-central, comm-central, *-aurora, *-beta, *-release, and also some of *-esr?? together in one repository, with, say, one toolkit/chrome/global/customizeToolbar.dtd file that has all the strings that are used by any of the apps on any branch.

We do have some experience with merging the content of localization files as part of l10n-merge which is run at Firefox build time. So this shouldn’t be too hard, right?

Enter version control, and the fact that quite a few of our localizers are actually following the development of Firefox upstream, patch by patch. That they’re trying to find the original bug if there’s an issue or a question. So, it’d be nice to have the history and blame in the resulting repository reflect what’s going on in mozilla-central and its dozen siblings.

Can’t we just hg convert and be done with it? Sadly, that only converts one DAG into another hg DAG, and we have a dozen. We have a dozen heads, and we want a single head in the resulting repository.

Thus, I’m working on creating that repository. One side of the task is to update that target repository as we see updates to our 12 original heads. I’m pretty close to that one.

The other task is to create a good starting point. Or, good enough. Maybe if we could just create a repo that had the same blame as we have right now? Like, not the hex or integer revisions, but annotate to the right commit message etc? That’s easy, right? Well, I thought it was, and now I’m learning.

To understand the challenges here, one needs to understand the data we’re throwing at any algorithm we write, and the mercurial code that creates the actual repository.

As of FIREFOX_AURORA_45_BASE, just the blame for the localized files for Firefox and Firefox for Android includes 2597 hg revisions. And that’s not even getting CVS history, but just what’s in our usual hg repository. Also, not including comm-central in that number. If that history was linear, things would probably be pretty easy. At least, I blame the problems I see in blame on things not being linear.

So, how non-linear is that history. The first attempt is to look at the revision set with hg log -G -r .... . That creates a graph where the maximum number of parents of a single changeset is at 1465. Yikes. We can’t replay that history in the target repository, as hg commits can only have 2 parents. Also, that’s clearly not real, we’ve never had that many parallel threads of development. Looking at the underlying mercurial code, it’s showing all reachable roots as parents of a changeset, if you have a sparse graph. That is, it gives you all possible connections through the underlying full graph to the nodes in your selection. But that’s not what we’re interested in. We’re interested in the graph of just our nodes, going just through our nodes.

In a first step, I wrote code that removes all grandchildren from our parents. That reduces the maximum number of parents to 26. Much better, but still bad. At least it’s at a size where I can start to use graphviz to create actual visuals to inspect and analyze. Yes, I can graph that graph.

The resulting graph has a few features that are actually already real. mozilla-central has multiple roots. One is the initial hg import of the Firefox code. Another is including Firefox for Android in mozilla-central, which used to be an independent repository. Yet another is the merge of services/sync. And then I have two heads, which isn’t much of a problem, it’s just that their merge commit didn’t create anything to blame for, and thus doesn’t show up in my graph. Easy to get to, too.

Looking at a subset of the current graph, it’s clear that there are more arcs to remove:

Anytime you have an arc that just leap-frogs to an ancestor, you can safely remove that. I indicated some in the graph above, and you’ll find more – I was just tired of annotating in Preview. As said before, I already did that for grandchildren. Writing this post I realize that it’s probably easy enough to do it for grandgrandchildren, too. But it’s also clear from the full graph, that that algorithm probably won’t scale up. Seems I need to find a good spot at which to write an explicit loop detection.

This endeavour sounds a bit academic at first, why would you care? There are two reasons:

Blame in mercurial depends on the diff that’s stored in the backend, and the diff depends on the previous content. So replaying the blame in some way out of band doesn’t actually create the same blame. My current algorithm is to just add the final lines one by one to the files, and commit. Whitespace and reoccurring lines get all confused by that algorithm, sadly.

Also, this isn’t a one-time effort. The set of files we need to expose in the target depends on the configuration, and often we fix the configuration of Firefox l10n way after the initial landing of the files to localize. So having a sound code-base to catch up on missed history is an important step to make the update algorithm robust. Which is really important to get it run in automation.

PS: The tune for this post is “That Smell” by Lynyrd Skynyrd.

March 23, 2017 02:01 PM

March 13, 2017

Mitchell Baker

The “Worldview” of Mozilla

There are a set of topics that are important to Mozilla and to what we stand for in the world — healthy communities, global communities, multiculturalism, diversity, tolerance, inclusion, empathy, collaboration, technology for shared good and social benefit.  I spoke about them at the Mozilla All Hands in December, if you want to (re)listen to the talk you can find it here.  The sections where I talk about these things are at the beginning, and also starting at about the 14:30 minute mark.

These topics are a key aspect of Mozilla’s worldview.  However, we have not set them out officially as part of who we are, what we stand for and how we describe ourselves publicly.   I’m feeling a deep need to do so.

My goal is to develop a small set of principles about these aspects of Mozilla’s worldview. We have clear principles that Mozilla stands for topics such as security and free and open source software (principles 4 and 7 of the Manifesto).  Similarly clear principles about topic such as global communities and multiculturalism will serve us well as we go forward.  They will also give us guidance as to the scope and public voice of Mozilla, spanning official communications from Mozilla, to the unofficial ways each of us describes Mozilla.

Currently, I’m working on a first draft of the principles.  We are working quickly, as quickly as we can have rich discussions and community-wide participation. If you would like to be involved and can potentially spend some hours reviewing and providing input please sign up here. Jascha and Jane are supporting me in managing this important project.  
I’ll provide updates as we go forward.  

March 13, 2017 06:28 PM

March 03, 2017

Axel Hecht

On updating the automation behind l10n.m.o

Or, how to change everything and nobody sees a difference.

Heads up: All I’m writing about here is running on non-web-facing VMs behind VPN.

tl;dr: I changed 5 VMs, landed 76 changesets in 7 repositories, resolving 12 bugs, got two issues in docker fixed, and took a couple of days of downtime. If automation is your cup of tea, I have some open questions at the end, too.

To set the stage: Behind the scenes of the elmo website, there’s a system that generates the data that it shows. That system consists of two additional VMs, which help with the automation.

One is nick-named a10n, and is responsible for polling all those mercurial repositories that we use for l10n, and to update the elmo database with information about these repositories as it comes in. elmo basically keeps a copy of the mercurial metadata for quicker access.

The other is running buildbot to do the actual data collection jobs about the l10n status in our source repositories. This machine runs both a master and one slave (the actual workhorse, not my naming).

This latter machine is an old VM, on old OS, old Python (2.6), never had real IT support, and is all around historic. And needed to go.

With the help of IT, I had a new VM, with a new shiny python 2.7.x, and a new storage. Something that can actually run current versions of compare-locales, too. So I had to create an update for

Python 2.6 Python 2.7.x
globally installed python modules virtualenv
Django 1.4.18 Django 1.8.x
Ubuntu CentOS
Mercurial 3.7.3 Mercurial 4.0.1 and hglib
individual local clones unified local clones
No working stage docker-compose up

At the same time, we also changed hg.m.o from http to https all over the place, which also required a handful of code changes.

One thing that I did not change is buildbot. I’m using a heavily customized version of buildbot 0.7.12, which is incompatible with later buildbot changes. So I’m tied to my branch of 0.7.12 for now, and with that to Twisted 8.2.0. That will change, but in a different blog post.

Unified Repositories

One thing I wanted and needed for a long time was to use unified clones of our mercurial repositories. Aside from the obvious win in terms of disk usage, it allows to use mercurial directly to create a diff from a revision that’s only on aurora against a revision that’s only on beta. Sadly, I did think otherwise when I wrote the first parts of elmo and the automation behind it, often falling back to default instead of an actual hash revision, if I didn’t know anything ad-hoc. So that had to go, and required a surprising amount of changes. I also changed the way that comparisons are triggered, making them fully reproducible. They also got more robust. I used to run hg id -ir . to get the revision, which worked OK, unless you had extension errors in stdout/stderr. Meh. Good that that’s gone.

As I noted, the unified repositories also benefit doing diffs, which is one of the features of elmo for reviewing localizations. Now that we can just use plain mercurial to get those diffs, I could remove a bunch of code that created diffs between aurora and beta by creating diffs between each head and some ancestor, and then sticking those diffs back together. Good that that’s gone.

Testing

Testing an automation with that many moving parts is hard. Some things can be tested via unit tests, but more often, you just need integration tests. I still have to find a way to write automated integration tests, but even manual integration tests require a ton of set-up:

Doing this manually is evil, and on Macs, it’s not even possible, because Twisted 8.2.0 doesn’t build anymore. I used to have a script that did many of these things, but that’s …. you guessed it. Good that that’s gone. Now I have a docker-compose test setup, that has most things running with just a docker-compose up. I’m still running elmo and MySQL on my host machine, fixing that is for another day. Also, I haven’t found a good way to do initial project setup like database creations. Anyway, after finding a couple of bugs in docker, this system now fires up quickly and let’s me do various changes and see how they pass through the system. One particularly nice artifact is that the output of docker-compose is actually all the logs together in one stream. So as you’re pushing things through the system, you just have one log to watch.

As part of this work, I also greatly simplified the code structure, and moved the buildbot integration from three repositories into one. Good that those are gone.

snafus

Sadly there were a few bits and pieces where my local testing didn’t help:

Changing the URL schemes for hg.m.o to https alongside this change triggered a couple of problems where Twisted 8.2 and modern Python/OpenSSL can’t get a connection up. Had to replace the requests to websites with synchronous urllib2.urlopen calls.

Installing mercurial in a virtualenv to be used via hglib is good, but WSGI doesn’t activate the virtualenv, and thus PATH isn’t set. My fix still needs some server-side changes to work.

I didn’t have enough local testing for the things that Thunderbird needs. That left that setup burning for longer than I anticipated. The fix wasn’t hard, just badly timed.

Every now and then, Django 1.8.x and MySQL decide that it’s a good idea to throw away the connection, and die badly. In the case of long-running automation jobs, that’s really hard to prevent, in particular because I still haven’t fully understood what change actually made that happen, and what the right fix is. I just plaster connection.close() into every other function, and see if it stops dying.

On Saturday morning I woke up, and the automation didn’t process Firefox for a locale on aurora. I freaked out, and added tons of logging. Good logging that is. Best logging. Found a different bug. Also found out that the locale was Belarus, and that wasn’t part of the build on Saturday. Hit my head against a wall or two.

Said logging made uncaught exceptions in some parts of the code actually show up in logs, and discovered that I hadn’t tested my work against bad configurations. And we have that, Thunderbird just builds everything on central, regardless of whether the repositories it should use for that exist or not. I’m not really happy yet with the way I fixed this.

Open Questions

March 03, 2017 08:01 PM

January 31, 2017

Mitchell Baker

A Thank You to Reid Hoffman

Today I want to say thank you to Reid Hoffman for 11 years as a Mozilla Corporation board member. Reid’s normal “tour of duty” on a board is much shorter. Reid joined Mozilla as an expression of his commitment to the Open Internet and the Mozilla mission, and he’s demonstrated that regularly. Almost five years ago I asked Reid if he would remain on the Mozilla board even though he had already been a member for six years. Reid agreed. When Chris Beard joined us Reid agreed to serve another two years in order to help Chris get settled and prime Mozilla for the new era.

Mozilla is in a radically better place today than we were two, three, or five years ago, and is poised for a next phase of growth and influence. Take a look at the Annual Report we published Dec 1, 2016 to get a picture of our financial and operational health. Or look at The Glass Room, or our first  Internet Health Report, or the successful launch of Firefox Focus (or Walt Mossberg’s article about Mozilla) to see what we’ve done the last few months.

And so after an extended “tour of duty” Reid is leaving the Mozilla Corporation board and becoming an Emeritus board member. He remains a close friend and champion of Mozilla and the Open Internet. He continues to help identify technologists, entrepreneurs, and allies who would be a good fit to join Mozilla, including at the board level.  He also continues to meet with and provide support to our key executives.

A heartfelt thank you to Reid.

January 31, 2017 05:06 PM

December 05, 2016

Mitchell Baker

Helen Turvey Joins the Mozilla Foundation Board of Directors

This post was originally posted on the Mozilla.org website.

Helen Turvey, new Mozilla Foundation Board member

Helen Turvey, new Mozilla Foundation Board member

Today, we’re welcoming Helen Turvey as a new member of the Mozilla Foundation Board of Directors. Helen is the CEO of the Shuttleworth Foundation. Her focus on philanthropy and openness throughout her career makes her a great addition to our Board.

Throughout 2016, we have been focused on board development for both the Mozilla Foundation and the Mozilla Corporation boards of directors. Our recruiting efforts for board members has been geared towards building a diverse group of people who embody the values and mission that bring Mozilla to life. After extensive conversations, it is clear that Helen brings the experience, expertise and approach that we seek for the Mozilla Foundation Board.

Helen has spent the past two decades working to make philanthropy better, over half of that time working with the Shuttleworth Foundation, an organization that provides funding for people engaged in social change and helping them have a sustained impact. During her time with the Shuttleworth Foundation, Helen has driven the evolution from traditional funder to the current co-investment Fellowship model.

Helen was educated in Europe, South America and the Middle East and has 15 years of experience working with international NGOs and agencies. She is driven by the belief that openness has benefits beyond the obvious. That openness offers huge value to education, economies and communities in both the developed and developing worlds.

Helen’s contribution to Mozilla has a long history: Helen chaired the digital literacy alliance that we ran in UK in 2013 and 2014; she’s played a key role in re-imagining MozFest; and she’s been an active advisor to the Mozilla Foundation executive team during the development of the Mozilla Foundation ‘Fuel the Movement’ 3 year plan.

Please join me in welcoming Helen Turvey to the Mozilla Foundation Board of Directors.

Mitchell

You can read Helen’s message about why she’s joining Mozilla here.

Background:

Twitter: @helenturvey

High-res photo

December 05, 2016 02:30 AM

December 01, 2016

Mitchell Baker

Julie Hanna Joins the Mozilla Corporation Board of Directors

This post was originally posted on the Mozilla.org website.

Julie Hanna, new Mozilla Corporation Board member

Julie Hanna, new Mozilla Corporation Board member

Today, we are very pleased to announce the latest addition to the Mozilla Corporation Board of Directors – Julie Hanna. Julie is the Executive Chairman for Kiva and a Presidential Ambassador for Global Entrepreneurship and we couldn’t be more excited to have her joining our Board.

Throughout this year, we have been focused on board development for both the Mozilla Foundation and the Mozilla Corporation boards of directors. We envisioned a diverse group who embodied the same values and mission that Mozilla stands for. We want each person to contribute a unique point of view. After extensive conversations, it was clear to the Mozilla Corporation leadership team that Julie brings exactly the type of perspective and approach that we seek.

Born in Egypt, Julie has lived in various countries including Jordan and Lebanon before finally immigrating to the United States. Julie graduated from the University of Alabama at Birmingham with a B.S. in Computer Science. She currently serves as Executive Chairman at Kiva, a peer-peer lending pioneer and the world’s largest crowdlending marketplace for underserved entrepreneurs. During her tenure, Kiva has scaled its reach to 190+ countries and facilitated nearly $1 billion dollars in loans to 2 million people with a 97% repayment rate. U.S. President Barack Obama appointed Julie as a Presidential Ambassador for Global Entrepreneurship to help develop the next generation of entrepreneurs. In that capacity, her signature initiative has delivered over $100M in capital to nearly 300,000 women and young entrepreneurs across 86 countries.

Julie is known as a serial entrepreneur with a focus on open source. She was a founder or founding executive at several innovative technology companies directly relevant to Mozilla’s world in browsers and open source. These include Scalix, a pioneering open source email/collaboration platform and developer of the most advanced AJAX application of its time, the first enterprise portal provider 2Bridge Software, and Portola Systems, which was acquired by Netscape Communications and become Netscape Mail.

She has also built a wealth of experience as an active investor and advisor to high-growth technology companies, including sharing economy pioneer Lyft, Lending Club and online retail innovator Bonobos. Julie also serves as an advisor to Idealab, Bill Gross’ highly regarded incubator which has launched dozens of IPO-destined companies.

Please join me in welcoming Julie Hanna to the Mozilla Board of Directors.

Mitchell

Background:

Twitter: @JulesHanna

High-res photo

 

December 01, 2016 07:18 PM

September 30, 2016

Mitchell Baker

Mozilla Hosting the U.S. Commerce Department Digital Economy Board of Advisors

Today Mozilla is hosting the second meeting of the Digital Economy Board of Advisors of the United States Department of Commerce, of which I am co-chair.

Support for the global open Internet is the heart of Mozilla’s identity and strategy. We build for the digital world. We see and understand the opportunities it offers, as well as the threats to its future. We live in a world where a free and open Internet is not available to all of the world’s citizens; where trust and security online cannot be taken for granted; and where independence and innovation are thwarted by powerful interests as often as they are protected by good public policy. As I noted in my original post on being named to the Board, these challenges are central to the “Digital Economy Agenda,” and a key reason why I agreed to participate.

Department of Commerce Secretary Pritzker noted earlier this year: “we are no longer moving toward the digital economy. We have arrived.” The purpose of the Board is to advise the Commerce Department in responding to today’s new status quo. Today technology provides platforms and opportunities that enable entrepreneurs with new opportunities. Yet not everyone shares the benefits. The changing nature of work must also be better understood. And we struggle to measure these gains, making it harder to design policies that maximize them, and harder still to defend the future of our digital economy against myopic and reactionary interests.

The Digital Economy Board of Advisors was convened to explore these challenges, and provide expert advice from a range of sectors of the digital economy to the Commerce Department as it develops future policies. At today’s meeting, working groups within the Board will present their initial findings. We don’t expect to agree on everything, of course. Our goal is to draw out the shared conclusions and direction to provide a balanced, sustainable, durable basis for future Commerce Department policy processes. I will follow up with another post on this topic shortly.

Today’s meeting is a public meeting. There will be two live streams: one for the 8:30 am-12:30 pm PT pre-lunch session and one for the afternoon post-lunch 1:30-3:00pm PT. We welcome you to join us.

Although the Board has many more months left in its tenure, I can see a trend towards healthy alignment between our mission and the outcomes of the Board’s activities. I’m proud to serve as co-chair of this esteemed group of individuals.

September 30, 2016 02:10 PM

September 28, 2016

Mitchell Baker

UN High Level Panel and UN Secretary General Ban Ki-moon issue report on Women’s Economic Empowerment

“Gender equality remains the greatest human rights challenge of our time.”  UN Secretary General Ban Ki-moon, September 22, 2016.

To address this challenge the Secretary General championed the 2010 creation of UN Women, the UN’s newest entity. To focus attention on concrete actions in the economic sphere he created the “High Level Panel on Women’s Economic Empowerment” of which I am a member.

The Panel presented its initial findings and commitments last week during the UN General Assembly Session in New York. Here is the Secretary General, with the the co-chairs, and the heads of the IMF and the World Bank, the Executive Director of the UN Women, and the moderator and founder of All Africa Media, each of whom is a panel member.

UN General Assembly Session in New York

Photo Credit: Anar Simpson

The findings are set out in the Panel’s initial report. Key to the report is the identification of drivers of change, which have been deemed by the panel to enhance women’s economic empowerment:

  1. Breaking stereotypes: Tackling adverse social norms and promoting positive role models
  2. Leveling the playing field for women: Ensuring legal protection and reforming discriminatory laws and regulations
  3. Investing in care: Recognizing, reducing and redistributing unpaid work and care
  4. Ensuring a fair share of assets: Building assets—Digital, financial and property
  5. Businesses creating opportunities: Changing business culture and practice
  6. Governments creating opportunities: Improving public sector practices in employment and procurement
  7. Enhancing women’s voices: Strengthening visibility, collective voice and representation
  8. Improving sex-disaggregated data and gender analysis

Chapter Four of the report describes a range of actions that are being undertaken by Panel Members for each of the above drivers. For example under the Building assets driver: DFID and the government of Tanzania are extending land rights to more than 150,000 Tanzanian women by the end of 2017. Tanzania will use media to educate people on women’s land rights and laws pertaining to property ownership. Clearly this is a concrete action that can serve as a precedent for others.

As a panel member, Mozilla is contributing to the working on Building Assets – Digital. Here is my statement during the session in New York:

“Mozilla is honored to be a part of this Panel. Our focus is digital inclusion. We know that access to the richness of the Internet can bring huge benefits to Women’s Economic Empowerment. We are working with technology companies in Silicon Valley and beyond to identify those activities which provide additional opportunity for women. Some of those companies are with us today.

Through our work on the Panel we have identified a significant interest among technology companies in finding ways to do more. We are building a working group with these companies and the governments of Costa Rica, Tanzania and the U.A. E. to address women’s economic empowerment through technology.

We expect the period from today’s report through the March meeting to be rich with activity. The possibilities are huge and the rewards great. We are committed to an internet that is open and accessible to all.”

You can watch a recording of the UN High Level Panel on Women’s Economic Empowerment here. For my statement, view starting at: 2.07.53.

There is an immense amount of work to be done to meet the greatest human rights challenge of our time. I left the Panel’s meeting hopeful that we are on the cusp of great progress.

September 28, 2016 09:54 PM

November 24, 2014

Staś Małolepszy

Meet.js talk on Clientside localization in Firefox OS

Firefox OS required a fast and lean localization method that could scale up to 70 languages, cater to the needs of hundreds of developers worldwide all speaking different languages and support a wide spectrum of devices with challenging hardware specs.

At the end of September, I went to Poznań to speak about localization technology in Firefox OS at Meet.js Summit. In my talk I discussed how we had been able to create a localization framework which embraces new Web technologies like Web components and mutation observers, how we'd come up with new developer tools to make localization work easier and what exciting challenges lay ahead of us.

November 24, 2014 11:10 AM

October 05, 2014

Axel Hecht

Update to the l10n team page

I’ve given the team pages on l10n.mozilla.org a good whack in the past few days. Time to share some details and get feedback before I roll it out.

The gist of it: More data in less screen space, I just folded things into rows, and made the rows slimmer. Better display of sign-off status, I separated status from progress and actions. Actions are now ordered chronologically, too.

The details? Well, see my recording where I walk you through:


View it on youtube.

Comments here or in bug 1077988.

October 05, 2014 02:02 PM

June 17, 2014

Axel Hecht

Create your own dashboard

We have a lot of data around localizations, but it’s hard to know what people might be looking for.

I just switched a new feature live, edit your own dashboard.

You can select branches of products, as well as the localizations you’re interested in, and get data you want.

Say you’re looking for mobile and India. You’d want Firefox OS and Firefox for Android aka Fennec. The latter is actively localized on aurora, so you’d want the gaia tree and fennec_aurora. You want Assamese, Bengali, Gujarati…. and 9 other languages. Select gu and pa, too, ’cause why not.

Or are you keen on Destop in Latin America? Again we’re looking at Aurora, so fx_aurora is our tree of choice this time. Locales are Spanish in its American Variants, and Brazilian Portuguese.

Select generously, you can always reduce your selection through the controls on the right side of the resulting dashboard.

Play around, and compare the Status and History columns. Try to find stories, and share them in the comments below.

A bit more details on fx-aurora vs Firefox 32. Right now, Firefox 32 is on the Aurora channel and repository branch. Thus, selecting either gives you the same data today. In six weeks, though, 32 is going to be on beta, so if you bookmark a link, it’d give you different data then. That’s why you can only select one or the other.

June 17, 2014 03:38 PM

May 27, 2014

Staś Małolepszy

Pseudolocales for Firefox OS

With bug 900182 fixed, it is now possible to enable pseudolocales in developer builds of Firefox OS. Pseudolocales are based on US English and are automatically generated according to strategies defined in build/l10n.js.
Presently, two pseudolocales can be enabled in custom Gaia builds:

A screenshot of Accented and Mirrored English

What to test

Pseudolocales make it easy to do localizability testing without the need of knowing a foreign language. The strategies used to autogenerate the pseudo-localized strings create text which is readable by an English speaker without much trouble.

How to build

Pseudolocales are enabled by default in custom builds of Gaia, so you can likely continue building it as you've always have:

make

For non-standard setups, use the following make flags:

GAIA_CONCAT_LOCALES=1 LOCALES_FILE=shared/resources/languages.json make

You can then go into Settings and change the language of the device in the Language panel. Or, you could set one of the pseudolocales to be the default locale from the get-go, with:

GAIA_DEFAULT_LOCALE=qps-ploc make

The pseudolocales are currently generated on build time as part of the webapps-optimize logic, and as such tey don't work in DEBUG=1 builds yet.

Next steps

An important piece of the initial pseudolocales work was the creation of a framework which allows adding new locales in the future. Accented and Mirrored English are the first two useful ones, but I'd like to add at least one more, and also improve the strategies for generating the existing ones.

I filed a few follow-up bugs. I think the following two are particularly interesting:

May 27, 2014 03:41 PM

May 22, 2014

Axel Hecht

Progress on l10n.mozilla.org

Today we’re launching an update to l10n.mozilla.org (elmo).

Team pages and the project overview tables now contain sparklines, indicating the progress over the past 50 days.

Want to see how a localization team is doing? Now with 100% more self-serve.

If the sparklines go up like so

good progress

the localization is making good progress. Each spark is an update (either en-US or the locale), so sparks going up frequently show that the team is actively working on this one.

If the sparklines are more like

not so much

then, well, not so much.

The sparklines always link to an interactive page, where you can get more details, and look at smaller or larger time windows for that project and that locale.

You should also look at the bugzilla section. A couple of bugs with recent activity is good. More bugs with no activity for a long time, not so much.

Known issues: We still have localizations showing status for central/nightly, even though those teams don’t work on central. Some teams do, but not all. Also, the sparklines start at some point in the past 50 days, that’s because we don’t figure out the status before. We could.

May 22, 2014 11:44 AM

April 08, 2014

Staś Małolepszy

Refactored l10n.js landed in Gaia

Today Zibi and I landed the refactored code of shared/js/l10n.js in Gaia master. A culmination of months of hard work, the refactor is also a first step of a larger initiative to innovate in the area of mobile localization and eventually, to implement L20n in Gaia.

Firefox OS faces a number of challenges related to localization. Growing the locale coverage beyond 20 supported locales; adapting to multiple screen sizes and form factors; ensuring the performance and memory consumption is good when the DOM is localized on the fly. In order to respond to these needs and many more that we will encounter in the future, we need a flexible and modular codebase, with a thought-out API designed to perform well in asynchronous scenarios.

We decided to re-write Gaia's l10n.js drawing from our experiences from developing L20n. The underlying concepts are similar: the code is organized into useful abstractions like the localization Context managing the fallback chain of Locale objects, or the Entity class which represents a single translation unit.

It's not L20n just yet. The library still uses the .properties file format.
There are no custom macros or arbitrary dicts which allow localizers greater flexibility in creating translations. The language fallback is limited to two locales. It still is a good first step towards empowering developers and localizers alike.

To minimize the risk of regressions, the refactored code was almost a drop-in replacement for the old l10n.js library. We decided to keep the exact same API of the navigator.mozL10n object. Everything should just work as it did before. We feel that there's room for improvement in the API design, and we'll soon start suggesting changes to it (e.g. bug 993188 has made many developers implement workarounds in their apps, which would break if we fixed it right away in our refactored drop-in patch).

Notable changes

Feedback and bugs

The top priority fot this refactor was to be 100% compatible with the old l10n.js library. We made sure all tests pass on Travis and on TBPL and put a lot of effort into writing additional tests. We will be monitoring the tree for any regressions. If you notice something weird going on with your device or your app, for instance related to language switching, please let us know.
File bugs in the newly created Gaia::L10n component in Bugzilla or find us in #gaia and #l20n.

Next steps

The list of tasks on our to-do list is long, but we couldn't be more exited about them. Ranging from UX improvements to developer-friendly APIs, to giving localizes more control over their translations, next months are going to be great for localization and Firefox OS. A sneak peek, in no particular order:

April 08, 2014 06:33 PM

November 07, 2013

Staś Małolepszy

L20n 1.0 Release Candidate now available

L20n 1.0 RC is now available for testing. We ask users of this release candidate to watch for and report any major bugs they encounter; if no release-blocking bugs are reported, L20n 1.0 will be released in approximately one week.

Following previous beta releases, this release adds the last big feature planned in the 1.0 scope: secure HTML localization which allows localizers to use some HTML in translations. Furthermore, two Context methods, ctx.get and ctx.getEntity, have been renamed to ctx.getSync and ctx.getEntitySync respectively.

You can download the RC from l20n.org (which also received an overhaul) or from the builds repository. To quickly get started, clone the demo repository, which contains an example HTML file localized with L20n (preview).

Changes since Beta 4

Following is a summary of the most notable changes since Beta 4. You can also consult the full changelog:

HTML localization

Secure HTML localization was one of the last big features on our 1.0 list. In Beta 4 and before, the developer could add the (now obsolete) data-l10n-overlay attribute to any HTML element to allow translations to have HTML content. The RC removes this attribute completely and allows a subset of HTML elements to be present in all translations, without any intervention from the developer.

In particular, text-level semantic elements like em and strong are now allowed in all translations, together with certain translatable attributes, like title and placeholder. This allows localizers to stay in control when it comes to deciding where to use some HTML to mark up the text (for instance, they can freely use the sup element in Mme). Similarly, HTML entities are also allowed and available at localizer's discretion (e.g. &nbsp;).

The documentation gives a few other examples demonstrating how the HTML in the translation is sanitized before it's inserted into the DOM. You may also be interested in learning the details of the implementation from the original thread on the mailing list, as well as from bug 921169 and bug 922576.

getSync and getEntitySync

We also take this opportunity to rename two methods available on Context instances. ctx.get is now ctx.getSync and can be used, as before, to synchronously get a translation string from the Context instance. ctx.getEntity becomes ctx.getEntitySync and can be used, also as before, to synchronously get a translation object consisting of the string value, attributes and the language code.

Nothing has changed in the behavior of these methods (they already were synchronous before), and the change to their names is cosmetic and keeps L20n forward-compatible. It allows us to focus more on our asynchronous API, which in turn makes it possible to continue our research into language packages for L20n and into running L20n (or parts of it) in worker threads.

In L20n 1.0, ctx.getSync doesn't have a direct asynchronous counterpart (bug 931707). Instead, we encourage everyone to use the ctx.localize API, which is asynchronous and supports retranslation when the language changes and when values of L20n's globals change (the concept known as responsive localization). Here's an example:

ctx.localize(['hello', 'about'], function(l10n) {
  var node = document.querySelector('[data-l10n-id=hello]');
  node.textContent = l10n.entities.hello.value;
  node.classList.remove('hidden');
});

The callback function will be invoked when the translations of hello and about are available. It will also be called again if the user changes the language, or when the values of L20n's globals like @screen change (but only if hello or about actually use them).

Testing the RC

If you take the Release Candidate for a spin (download from l20n.org or clone the demo repository), please report any bugs that you find (or things that look like bugs). Pending any new release-blocking bugs, we will release 1.0 final in approximately one week.

You can file bugs in Bugzilla, or find us in #l20n on irc.mozilla.org, or email the tools-l10n mailing list. Thank you!

November 07, 2013 01:37 PM

October 18, 2013

Staś Małolepszy

Prototype of Language Packages for Firefox OS

Making Firefox OS available in as many languages as possible is part of Mozilla's mission to give users the freedom of choice and let them be in control of their online experience.

To this end, Zibi and I have implemented a prototype of user-installable language packages, or langpacks, which are downloaded to the device when the user requests them. Watch the short video below to see them in action.

How the prototype works

We started with a simple language package server in node.js which is periodically pinged by Firefox OS and returns the list of languages that the server has available for a given set of apps. This list is used to build the language choice menu in the Settings app. When the user selects a language which is not installed on the device, the server is queried again and the corresponding language resources are downloaded. Currently, only very basic version-checking is being done and we'd like to explore versioning of langpacks further in the next iteration.

Ideally, this would happen independently of the user's running any apps, in a background service. The list of additional languages available on the server would be synchronized periodically, and stored locally on the device. The Data Store API might be useful for making this data available to other apps.

Since there are no background services in Firefox OS yet, we implemented the prototype in every app. We're looking into Service Workers as potentially being the right solution to extracting this logic into a single component.

Lastly, langpacks currently comprise of translation files only, and don't provide additional keyboard layouts (although the Keyboard IME API should make this possible), nor do they change the translated names of apps which are stored in webapp manifests.

Why langpacks are important

Langpacks have a number of advantages and scalability is only one of them. Instead of pre-installing all available languages on each device sold around the world, langpacks let the user decide which language they need (and which they don't). They make it possible to decouple localization updates from OS updates and updates of individual apps, which might be useful for testing and for releasing early versions of localizations to gather feedback.

Where I see langpacks shine is in the fact that they move the decision making from developers to localizers and users. If pre-installing languages on the device is 'push', then langpacks are 'pull'. With langpacks, the community can test new translations easily. We can cater to the needs of minority languages. And the users can decide which languages they want to have their devices available in.

October 18, 2013 10:21 AM

September 19, 2013

Axel Hecht

A tale of convert and convert

Or, how I made converting gaia to gaia-l10n suck less.

Background: For Firefox OS, we’re exposing a modified repository to localizers, so that it’s easier to find out what to work on, and to get support from the l10n dashboards. Files in the main gaia repository on github like

apps/browser/locales/browser.en-US.properties

should become

apps/browser/browser.properties

and the localizable sections in manifest.webapp,

{
…
  "locales": {
    "en-US": {
      "name": "Browser",
      "description": "Gaia Web Browser"
    }
…
}

are exposed in manifest.properties as

name: Browser
description: Gaia Web Browser

We’re also not supporting git on the l10n dashboard yet, so we need hg repositories.

I haven’t come across a competitor to hg convert on the git side yet, so I looked on the mercurial side of life. I started by glancing of the code in hgext/convert in the upstream mercurial code. That does a host of things to get parents and graphs right, and I didn’t feel like replicating that. It doesn’t offer hooks for dynamic file maps, though, let alone content rewriting. But it’s python, and it’s open-source. So I forked it.

With hg convert. Isn’t that meta? That gives me a good path to update the extension with future updates to upstream mercurial. I started out with a conversion of mercurial 2.7.1, then removed all the stuff I don’t need like bzr support etc. Then I made the mercurial code do what I need for gaia. I had to disable some checks that try to avoid commits that don’t actually change the contents, because I don’t mind that happening. And last but not least I added the filemap and the shamap of the initial conversion of hgext/convert, so that future updates don’t depend on my local disk.

Now I could just run hg gaiaconv and get what I want. Enter the legacy repositories for en-US. We only want fast-forward merges in hg, and in the conversion to git. No history editing allowed. But as you can probably guess, the new history is completely incompatible with the old, from changeset one. But I don’t mind, I hacked that.

I did run the regular hg gaiaconv up to the revision 21000 of the integration/gaia-central repository. That ended up with the graph for revision 4af36780fb5d.

gaia-central conversion

I pulled the old conversion for v1-train, which is the graph for revision ad14a618e815.

old en-US for v1-train

Then I did a no-op merge of the old graph into the new one.

merge

That’s all good, but now future conversions via gaiaconv would still pick up the non-merged revision. Well, unless one just edits the generated shamap, and replaces all references to 4af36780fb5d with cfb28f851111. And yes, that actually works.

more conversions post-merge

Tadaaa, a fully automated conversion process, and only forward merges.

Repositories involved in this post:

September 19, 2013 02:49 PM

February 15, 2013

Axel Hecht

Risk management for releases at scale

Let me share some recent revelations I had. It all started with the infamous Berlin airport. Not the nice one in Tegel, but the BBI desaster. The one we’ve thought we’d open last year, and now we don’t know which year.

Part of the newscoverage here in Germany was all about how they didn’t do any risk analysis, and are doomed, and how that other project for the Olympics in London did do risk analysis, and got in under budget, ahead of time.

So what’s good for the Olympics can’t be bad for Firefox, and I started figuring out the math behind our risk to ship Firefox, at a given time, with loads of localizations. How likely is it that we’ll make it?

Interestingly enough, the same algorithm can also be applied to a set of features that are scheduled for a particular Firefox release. Locales, features, blockers, product-managers, developers, all the same thing :-). Any bucket of N things trying to make a single deadline have similar risks. And the same cure. So bear with me. I’ll sprinkle graphs as we go to illustrate. They’ll link to a site that I’ve set up to play with the numbers, reproducing the shown graphs.

The setup is like this: Every single item (localization, for exampe) has a risk, and I’m assuming the same risk across the board. I’m trying to do that N times, and I’m interested in how likely I’ll get all of them. And then I evaluate the impact of different amounts of freeze cycles. If you’re like me, and don’t believe any statistics unless they’re done by throwing dices, check out the dices demo.

Anyway, let’s start with 20% risk per locale, no freeze, and up to 100 locales.

80%, no freeze, up to 100

Ouch. We’re crossing 50-50 at 3 items already, and anything at scale is a pretty flat zero-chance. Why’s that? What we’re seeing is an exponential decay, the base being 80%, and the power being how often we do that. This is revelation one I had this week.

How can we help this? If only our teams would fail less often? Feel free to play with the numbers, like setting the successrate from 80% to 90%. Better, but the system at large still doesn’t scale. To fight an exponential risk, we need a cure that’s exponential.

Turns out freezes are just that. And that’d be revelation two I had this week. Let’s add some 5 additional frozen development cycles.

80%, 5 freezes, up to 100

Oh hai. At small scales, even just one frozen cycle kills risks. Three features without freeze have a 50-50 chance, but with just one freeze cycle we’re already at 88%, which is better than the risk of each individual feature. At large scales like we’re having in l10n, 2 freezes control the risk to mostly linear, 3 freezes being pretty solid. If I’m less confident and go down to 70% per locale, 4 or 5 cycles create a winning strategy. In other words, for a base risk of 20-30%, 4-5 freeze cycles make the problem for a localized release scale.

It’s actually intuitive that freezes are (kinda) exponentially good. The math is a tad more complicated, but simplified, if your per-item success rate is 70%, you only have to solve your problem for 30% of your items in the next cycle, and for 9% in the second cycle. Thus, you’re fighting scale with scale. You can see this in action on the dices demo, which plays through this each time you “throw” the dices.

Now onwards to my third revelation while looking at this data. Features and blockers are just like localizations. Going in to the rapid release cycle with Firefox 5 etc, we’ve made two rules:

That worked fine for a while, but since then, mozilla has grown as an organization. We’ve also built out dependencies inside our organization that make us want particular features in particular releases. That’s actually a good situation to be in. It’s good that people care, and it’s good that we’re working on things that have organizational context.

But this changed the risks in our release cycle. We started off having a single risk of exponential scale after the migration date (l10n). Today, we have features going in to the cycle, and localizations thereof. At this point, having feature-freeze and string-freeze being the same thing becomes a risk for the release cycle at large. We should think about how to separate the two to mitigate the risk for each effectively, and ship awesome and localized software.

I learned quite a bit looking at our risks, I hope I could share some of that.

February 15, 2013 03:26 PM

September 27, 2012

Axel Hecht

Language packs are restartless now

Language packs are add-ons that you can install to add additional localizations to our desktop applications.

Starting with tomorrow’s nightly, and thus following the Firefox 18 train, language packs will be restartless. That was bug 677092, landed as 812d0ba83175.

To change your UI language, you just need to install a language pack, set your language (*), and open a new window. This also works for updates to an installed language pack. Opening a new window is the workaround for not having a reload button on the chrome window.

The actual patch turned out to be one line to make language packs restartless, and one line so that they don’t try to call in to bootstrap.js. I was optimistic that the chrome registry was already working, and rightfully so. There are no changes to the language packs themselves.

Tests were tricky, but Blair talked me through most of it, thanks for that.

(*) Language switching UI is bug 377881, which has a mock-up for those interested. Do not be scared, it only shows if you have language packs installed.

September 27, 2012 11:04 AM