The importance of reviewing suggestions

Delphine

1 response

While at Mozilla we want to ensure consistent and high-quality translations, we also want to make sure that contributing is a rewarding and pleasant experience for everyone. Translating in a timely manner is important, however there are other essential things to take into consideration. For example, leaving non-urgent projects with missing strings so that new localizers can get involved is one of them. Reviewing pending suggestions regularly is another – and the main topic of this post.

In the last few months, the l10n-drivers Project Management group (Delphine, Peiying, Flod, Jeff, and Théo) has taken a good look at the state of pending suggestions across teams and projects in Pontoon, and has decided to take more direct action in order to ensure that localizers (newcomers and old timers alike) get timely and constructive reviews. In fact, a lack of timely replies – or worst, a total lack of replies – creates an unwelcoming environment and risks losing contributors.

We started reaching out to some teams individually – but given the amount of locales concerned, it seems a broader “call to action” at this moment is a better way to kick things out.

As a first step, we’d like communities that have more than 300 pending suggestions to go through these and take some time to bring that number down. In fact, our goal this year is not only to get a better picture of the health of the localization communities, but also to take action in order to ensure our localization communities are thriving and healthy. This is just one of many steps to get there.

The reality is that when a locale has hundreds or thousands of unreviewed suggestions, and that remain unreviewed for months, it creates an unwelcoming environment for newcomers who could have a high impact on the project with some mentorship. Seeing these high numbers will make new potential localizers think that no one is paying attention, that they will not be able to get involved effectively and that they won’t be able to make an impact. In addition to being unwelcoming, this slowly creates a closed localization community, as the lack of reviews and transparency restrict involvement to only a handful of localizers (or in some cases, one localizer alone).

In the case of teams that have thousands of unreviewed strings, one way that they can start thinking about this is if there are any projects that have become less important, that they are less passionate about, and that they do not want to work on anymore. In this case, they can simply reach out to the Project Manager in charge in order to discuss the situation. The Project Manager can also easily be found on the Pontoon UI under each project page, next to the “Contact Person” field. If still in doubt, simply reach out to the dev-l10n mailing list and we will gladly respond from there.

So, what are our next steps here? Starting in July, we will reach out to teams that still have more than 300 pending suggestions and ask that they bring that number down. In lack of response, or if no action on pending suggestions is taken, we will carefully evaluate which contributors to give more permissions to and assign translator rights to new particularly active localizers. We will also talk with them on how to coordinate the localization activity for the locale.

So this is a call to action for every locale that has pending suggestions: please help us ensure that we all have a great experience in localization at Mozilla, by not only welcoming and onboarding newcomers in your team – but also making sure everyone gets a timely review of their work.

Pontoon documentation explains what a healthy localization workflow can look like, and we invite you to take a look at it here.

Tags are now available in Pontoon to help you prioritize your work

Francesco Lodolo [:flod]

2 responses

Almost a couple of years ago I started working on a concept called string tiers. The goal was twofold: on one side help locales, especially those starting from scratch, to prioritize their work on a project as large as Firefox, with currently over 11 thousand strings. On the other hand, give project managers a better understanding of the current status of localization.

Given the growth in complexity and update frequency of Developer Tools within Firefox (currently almost 2,600 strings), finding a solution to this problem became more urgent. For example, is a locale in bad shape because it misses thousands of strings? The answer would not automatically be ”yes”, since the missing strings might have a low priority.

The string tiers concept assigns priority to strings based on their target – who is meant to see them – and their visibility. The idea is quite simple: a string warning the user about an error, or requiring an action from them, is more important than one targeting developers or website owners, and buried in the Error Console of the browser.

If you’re interested in knowing more about string tiers, the full document is available here.

In the past few months the Pontoon team – Ryan and Matjaz in particular – has been working hard to implement the back-end for supporting string tiers. Since the system can be used for more than just priority, we decided to use a more generic term: tags. Translation resources – files in the case of Firefox, not individual strings – can be associated to one or more tags.

A dashboard is available in each localization page, for example for the German localization of Firefox:

At a glance you have access to all the information you need: the priority associated to a tag, its translation status and latest activity. You can use the progress bar to access the strings, for example to translate missing strings or review suggestions, but note that tags are also available in filters.

Pontoon’s documentation is already up to date with information about tags.

Project managers can now see the overall translation status of each tag, but also a breakdown with the status of each locale for a specific tag.

This is a brand new feature, and required a lot of code changes in Pontoon. If you find bugs, or want to add features, feel free to file a bug.

L10N Report: May Edition

Delphine

No responses yet

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

  • Kumar Ritu Raj just finished localizing and testing Focus Android v5 in Angika language (which is going to launch soon!) and he is doing BCA from TP College, BNMU, Bihar, India. Welcome and congratulations!
  • Common Voice: Jimi of Danish and Dimitris of Greek, thank you for taking the lead in your respective language.

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

New community/locales added

  • We recently added several locales to Pontoon: Arpitan (frp), Canadian English (en-CA), Cornish (kw), Iloko (ilo). If you speak any of these languages and want to help, take a look at Pontoon or get in touch.

New content and projects

What’s new or coming up in Firefox desktop

Activity Stream

Activity Stream has become an integral part of Firefox, officially replacing the existing New Tab and soon integrating code for displaying snippets and onboarding content. For this reason, we’re working on moving translations to mozilla-central.

Currently, Activity Stream is managed as a stand-alone project in Pontoon, and store its translations in a GitHub repository. Once this meta bug is fixed, Activity Stream’s strings will be exposed as part of the Firefox project.

While this makes the relation between Activity Stream and Firefox more obvious for localizers, it will also allow to make some improvements in the future, like reducing the lag between translations landing in repositories and actually being available for testing in Firefox.

Release schedule

There are some changes in the release schedule for the Summer, with the Nightly cycle for 63 lasting 10 weeks instead of 8, and the effects of this change rippling to the end of year.

Does this impact you as a localizer? Luckily, not really, thanks to cross-channel. Just don’t forget to keep an eye on the deadlines in Pontoon for the Firefox project, and you’ll be all set.

If you’re curious, you can always check the official Release Calendar.

Fluent migrations

We were waiting for the 61 Nightly cycle to end before resuming migrations. The first bug on the schedule for 62 landed on Tuesday and migrated almost 30 strings used in Privacy related permission dialogs (camera, location, pop-ups, etc.), with a second one already in review (over 20 strings, used in JavaScript across subdialogs in Preferences).

Shield studies

Shield studies are A/B tests, deployed to a specific portion of Firefox users, designed to test features or changes and analyze their impact.

So far, these studies have been targeting only English users (with one exception), and didn’t require localization. This week we started localizing our first study: it’s an extension that will be enabled initially only for Nightly, and for a limited number of locales (4) that have a significant population on the Nightly channel. We will also expose the opt-out preference for Shield studies, together with the about:studies page, to all languages in Firefox in the coming days.

If you’re interested in Shield studies, you can find more details in this wiki page.

What’s new or coming up in mobile

There’s been quite a few things going on in mobile world recently, as you’ve probably noticed.

We’ve recently exposed strings for the upcoming release of Firefox iOS v12, that aims to launch around June 12th. The tentative deadline for localizing and testing is May 23rd. Screenshots are updated twice a week.

Firefox for Amazon Fire TV is shipping an update very soon, probably some time next week. We’ll be getting updated screenshots for testing very soon, stay tuned!

Same for Focus Android v5 that is coming up, and will feature three new locales: Angika (anp), Cornish (kw) and Purépecha (tsz). Congrats to the localizers involved in this effort!

Firefox for Android is updating to v60 as we speak, and is being progressively rolled out to users.

What’s new or coming up in web projects

Common Voice was launched on May 2nd in 29 languages. Thanks to many communities’ active participation to get to the finish line, especially with quite a bit of last minute changes. More languages will be added as they reach the completion criteria.

The team has been continually impressed with the thoroughness of communities around the globe down to the wire, to test, to identify issues, and they have not stopped just because the product or their language is launched. The bugs keep coming, not just for translation but for site stability and UX issues. Here is one example.

Currently, only the website is localizable. The next step is to start recording voices in new languages. To that end, we need sentences for people to read in these new languages. The Common Voice team is participating the Mozilla’s Global Sprint to help collect and review new sentences for people to read. Only after that, the team will start collecting voice data in a new language.

What’s new or coming up in Foundation projects

On the advocacy and fundraising side, we’ve had an opportunity to respond to the Clear History feature announced by Facebook during the F8 conference, but the team is mostly focusing on the long term strategy on how to move the conversation to the broader data and privacy topic.

What’s new or coming up in Pontoon

We’re happy to announce that Vishal Sharma and Pramit Singhi will be joining us for the Google Summer of Code project this year! They will help us improve the path to first contribution, including the homepage redesign and guiding new users to submitting their first translation. That should help us grow l10n communities.

Pontoon now runs compare-locales checks when you submit a translation – the same library that is used during the Firefox build process. That allows Pontoon to prevent you from submitting translations that can break Firefox. Read more about the updates we made to the way quality checks work.

Pontoon now allows you to translate strings across all projects in a single translation interface, which helps you work on all untranslated strings in one go, or review all pending suggestions submitted by your team contributors. We also changed the way search works by bringing it closer to the default behaviour of search engines.

More relevant communications for Engagement projects

https://irccloud.mozilla.com/file/Amhzza0T/Schermata%202018-05-09%20alle%2012.28.53.png

We realized that several communications we send to the dev.l10n.web mailing list concern only a small subset of locales, and are meant to be ignored by the vast majority of people. In order to keep the signal-to-noise ratio low, we are changing the way we communicate project updates like snippets and newsletters. From now on, we will try to rely as much as possible on Pontoon built-in notification system, allowing us to send notifications only to existing contributors in the target locales. This way, communications in dev.l10n.web should be more relevant for everyone.

This also means people contributing to Engagement projects won’t get notification directly in their inbox, but using the Pontoon Tools add-on from Michal Stanke will get you almost real-time notifications in your browser. If you’re usually contributing to those projects, please keep an eye on Pontoon notifications if you don’t want to miss schedule, deadline or context about new content.

Events

If you’re planning to meet your fellow teammates this year, or planning an event with other locales, make sure to check our plans for l10n meetups in 2018 and the process to organize meetups. We can’t wait to see the meetup ideas you may have!

  • Want to showcase an event coming up that your community is participating in? Reach out to any l10n-driver and we’ll include that (see links to emails at the bottom of this report)

Localization impact by the numbers

Snippets

  • In Q1, 78 localized snippets generated 2,131,516,000 impressions (for real!!).
  • Of the 78 snippets, 26 snippets had links that generated 125,000 clicks (whoa!!).

Friends of the Lion

Image by Elio Qoshi

 

  • Felix, also known as Djfe, leads the way in filing the number of issues for Common Voice project. Reported problems include translations, functionality testing and UI designs. Thank you for your active participation as a localizer and as a Mozillian!

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.

Making it hard to break Firefox from Pontoon

Matjaž Horvat

No responses yet

When submitting a translation, Pontoon runs automated quality checks. They identify issues with punctuation, capitalization, variables, etc. before translations are saved, which prevents localizers from submitting bad translations. We just launched several improvements to the way quality checks work, so let’s have a look.

Using compare-locales checks in Pontoon

In addition to internal Pontoon checks and Translate Toolkit checks, Pontoon now also runs compare-locales checks. They are used when building Firefox, so it’s much harder now for localizers to break Firefox builds by submitting a bad translation through Pontoon.

Errors and warnings

There are two types of quality check failures now: errors and warnings.

Errors cover issues that would cause the translation to be unused in product, for example removed from Firefox builds or mozilla.org. For this reason, errors cannot be bypassed by localizers – the button to submit a translation is removed and the error needs to be fixed before the translation can be saved.

Errors are denoted with a red circled X

Errors are denoted with a red circled X.

Warnings, unlike errors, are displayed when we’re not completely sure that the string contains critical issues (false positives). For that reason, warnings can be bypassed by localizers – they can save a translation anyway.

Note: since Translate Toolkit checks may result in many false positives in some scenarios, they can be turned off using the Translate Toolkit Checks toggle (previously called Quality Checks).

Next steps

Thumbs up to Jotes for turning this long awaited feature into a reality! He’s already busy with the next step, which is storing information about the failed checks in a database. Once that’s in place, we’ll start performing quality checks during sync and finally present the information about errors and warnings on dashboards.

L10n community events in 2018

Jeff Beatty

No responses yet

From 2014-2017, the l10n-drivers assumed responsibility for organizing localization sprints, hackathons, and workshops. We went from hyper-local meetups to large-scale meetups (in Berlin’s workshop last year we had 50+ localizers present). Feedback from the community over the years has taught us that the format of these workshops had grown stale and localizers desired to have more opportunities to self-organize their own meetups.

Continue reading …

Localization Workshop in Kolkata (November 2017)

Francesco Lodolo [:flod]

No responses yet

In case you’re wondering “Uhm, what year are we in again?”, don’t worry: it’s April 2018, and this is a long overdue post that I owe to our large community of Indic locales.

Last November, Jeff, Peiying and I (flod) headed to Kolkata for the last of our planned localization workshops. The group of languages represented at the event included Bengali (both Bangladesh and India), Gujarati, Hindi, Kannada, Marathi, Nepali, Odia, Tamil and Telugu. If you’re surprised by the number of languages, consider that India alone has 22 languages listed in the Indian Constitution, but that’s only the tip of the iceberg, with a much larger variety of languages spoken, and sometime officially recognized at the State level.

IMG_8927After successfully testing the unconference approach in previous events, like Berlin during the summer, we decided to push the boundaries and enter the weekend without an agenda: localizers would own the event, propose topics at the beginning of each day, vote on a schedule, and drive the discussions. In hindsight, I think this was a successful experiment: several participants came up with topics and in some case gave presentations on subjects they cared about. I felt like every person in the room was able to actively participate and be heard.

Workshop Kolkata 2017Here are a few personal takeaways:

  • Locales in the area share the same struggle that other communities express: it’s hard to find new contributors, it requires a lot of time and resources to train them, and they might end up leaving the project shortly after. For sure, we should – and will – invest in making mentorship easier in Pontoon. We want to be able to have discussions about translations directly within the tool, to track quality metrics over time for each contributor, and not risk losing potential contributors when managers are inactive for an existing locale.
  • They feel a struggle with other parts of the Mozilla project, attracting volunteers from different functional areas. That’s something that we haven’t heard in previous events, and it might be explained with the success of specific initiatives in the region.
  • The usage of local languages vs English is quite low in India, compared to other areas of the world. We know there are some possible cultural explanations for this, for example knowing English could represent a mean to a better job, but we also look forward to the multilingual improvements that we plan for 2018/19, to see if that’s going to change the situation by lowering the barrier to access other languages within the browser.
  • It’s always fruitful to spend some time showing how to test the browser, and how to use tools like Pontoon and Transvision. And, this time, I didn’t even have to do a presentation about Transvision (it was proposed and driven Mak from bn-BD) 🙂

You can also read the report of the event from the localizers’ perspective, with a lot more details on the discussions, by reading the blog posts from Drashti, Bala and Selva.

Workshop Kolkata 2017A big thanks to Biraj for helping with the organization, giving us a brief tour of the city, and making my first trip to India a pleasant experience.

L10N Report: April Edition

Delphine

No responses yet

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

  • German: Felix came to us through the Common Voice project. He is now actively involved in Engagement and MDN projects.
  • For the new Ixil locale, we have 4 new l10n community members: Miguel Eliseo, Miguel, Manuela and Gerardo. Welcome to all!

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

New community/locales added

  • Ixil (“ixl”) is a new community that just got added this week, and already started working on Focus for Android. Ixil is a Mayan language spoken in Guatemala, and you can learn more about it here. Welcome!

New content and projects

What’s new or coming up in Firefox desktop

In the past weeks we have completed the migration to Fluent of all XUL panes in Preferences. Today we landed one more major bug, migrating about 150 strings that cover the XUL portion of all the subdialogs (Fonts, Languages, Proxy, Colors, etc.). This leaves out only a few edge cases that require code changes in Fluent itself, and some strings in .properties files used also outside of Preferences. As of today, only 14 strings remain in DTD files, and 115 in .properties.

Given the extent of the changes we’re doing, make sure to test your localization on Nightly, and report any issue you find in migrated strings, or in the way Preferences work with Fluent.

In case you’ve missed it, this week we also published a blog post explaining what’s been done to integrate CLDR data into Firefox in the past months, and the next steps for 2018.

One final reminder: Firefox 60 is an ESR version, and it’s possible to localize strings only until April 25. Make sure to complete translations before this deadline, and give yourself enough time to test, otherwise they won’t be included in this release.

What’s new or coming up in mobile

This month has been packed with good stuff in mobile land. Firefox for iOS v11 just launched with RTL support, which means we are now shipping our Arab, Hebrew, Persian and Urdu localizations. We now have RTL support on all our mobile projects, which is a really great accomplishment. Congrats and THANKS to all those involved in this! You can also learn more about this latest update of Firefox iOS 11 on the Mozilla blog: Latest Firefox for iOS Now Available with Tracking Protection by Default plus iPad Features

We’re now shipping eight new locales on Firefox iOS with this new version: Aragonese (an), Arabic (ar), Persian (fa), Hebrew (he), Croatian (hr), Georgian (ka), Occitan (oc) and Urdu (ur). Congrats to all these teams!

Vietnamese (vi) is a new language that shipped on Firefox Android 59 last month, so congrats to the team on getting that going too.

On Focus Android side, we had five new locales ship with v4.1: an (Aragonese), gu-IN (Gujarati), hr (Croatian), oc (Occitan) and tt (Tatar). We are now at a total of 75 shipping locales on Focus for Android \o/

To conclude, just like for desktop, a friendly reminder that it’s only possible to localize strings for Firefox Android 60 until April 25.

What’s new or coming up in web projects

The CPG, or the Community Participate Guidelines, has been published for a while. We now make it a bit more discoverable by adding it to the Pontoon Term page. Please take a read of the document if you haven’t had a chance before. Whenever the guideline is updated, you will be prompted to review the amendment before proceeding on Pontoon. We encourage you to periodically refer to these guidelines when collaborating with others from different regions and cultures, and especially when resolving differences.

The Common Voice project has brought quite a few new contributors to many communities. This is very exciting! These contributors are new to Pontoon, probably new to the localization process and to the way Mozilla localization community works. As a manager or a translator for enabled locales, please review the suggestions in a timely manner, provide constructive feedback, and re-evaluate the roles of these new localizers based on the quality of their work. Additionally, reach out to them, and get them signed up to the web project mailing list.

What’s new or coming up in Foundation projects

Facebook & Privacy campaign

 

Last month we reported that things were quiet on the campaign side of things. Well, it didn’t last long. All of you should be aware of the Facebook / Cambridge Analytica scandal by now. We launched a Rapid Response campaign, and this is the first time we’re localizing it, so here are some details of what happened over the past few weeks.

Here’s a rough timeline of events on the Policy/Advocacy side:

  • The news broke over the weekend of March 18th.
  • On Monday, it has been decided to launch a Rapid Response campaign, and localize it. First time we’re doing that!
  • By Monday evening, we had a campaign strategy. An email & a petition were drafted and went through an expedite approval process. Many teams at Mozilla were all hands on deck, including top executives. We began localizing the email right after this.
  • On Tuesday morning we evaluated our options to localize the petition on our brand new website, which does not have localization support. We found a hacky way to publish multiple pages with the same petition, so we just did that for localized petitions. It’s not perfect, but we had to be creative!
  • By Tuesday evening, the email was translated into French, German, Spanish and Brazilian Portuguese. Translated emails were coded into our emailing platform and email proofs were sent to localizers for a formal approval. Translated petitions were also pushed live.
  • On Wednesday, localized emails were sent, covering the vast majority of Mozilla subscribers!

We were able to help launch the initial petition and email into five languages in less than 72 hours. It’s been incredibly helpful to be able to mobilize so many people in just a few hours. It turned out the multiple initiatives launched by Mozilla & other organizations have been noticed by Facebook and they did what we asked — update their privacy settings.

Thanks to everyone who helped translate, review and approve these messages!

What’s next?

This is a first win towards a healthier Internet, but we won’t stop just yet. It’s actually a great way to engage on these critical issues. The campaign will continue over the next few months. We will keep widening the debate to other aspects of online privacy where we can, and not focus exclusively on Facebook. And try to move the debate outside the U.S., because everyone is affected by those issues.

On the localization side, we’re not yet in an ideal position where we can scale our localization efforts, but this first Rapid Response campaign has been encouraging and it will help shape up the next steps of our work.

Internet Health Report

Mozilla released the Internet Health Report 2018, you should check it out! It comes right on time and is quite relevant at a time where data & privacy issues are in the headlines. There is also an interesting piece on Building a multilingual Internet. Also feel free to report issues using this GitHub repository.

Newly published localizer facing documentation

Pontoon documentation has been updated to reflect the new search capabilities, and possibility to search and translate across all projects.

Events

  • Read this blog post in case you want to know what’s cooking in regards to localization community events planning in 2018 (and more)!
  • Want to showcase an event coming up that your community is participating in? Reach out to any l10n-driver and we’ll include that (see links to emails at the bottom of this report)

 

Friends of the Lion

 

Image by Elio Qoshi

Huge thank you to Guillermo Movia, Drashti, Irvin Chen, Cécile Bertin and Mozinet for reporting issues on the Internet Health Report. And to Cécile for also completing the French translation of the Talk plugin from the Coral Project, which is used in the report.

  • 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.

CLDR as source of key internationalization data in Firefox: milestones achieved and next steps

Francesco Lodolo [:flod]

No responses yet

In case you’re not familiar with the acronym, CLDR stands for Common Locale Data Repository: it’s a repository of locale data maintained by the Unicode Consortium, and used in several libraries that power internationalization (i18n) features in products developed by Mozilla, Apple, IBM, Microsoft, and many other companies. Firefox uses the data provided by CLDR mostly through the ICU library.

You can find an exhaustive list of the type of data provided in the CLDR home page. Within Firefox, these are currently the main focus areas:

  • Date and time formatting, calendar preferences.
  • Plural cases.
  • Translation of language and region names.

Date and time formatting, calendar preferences

Firefox 57 shipped with a native datetime picker that can be used in HTML forms. Here’s how it looks in Italian:

The localization data used to generate this dialog comes from CLDR:

  • Date formatting for the placeholder.
  • Month and day names.
  • First day of the week (e.g. Sunday for en-US, Monday for it).

The same data is also available to Firefox developers to properly internationalize other parts of the user interface. It’s provided via an API called ‘mozIntl’, which extends the standard JavaScript Internalization library (ECMA402).

Firefox 61 will also ship with a relative time format API (“in 5 seconds”, “5 seconds ago”), finally allowing front-end developers to use a more natural language in the interface.

Plural cases

Currently, there are 3 completely different sources of truth for plurals:

  • Fluent uses CLDR to determine the number of plural forms for each language, and CLDR categories (zero, one, two, few, other, many).
  • Pontoon stores its own internal rules, using CLDR categories.
  • Gecko stores an internal plural rule, in form of a localizable key with an integer value. Each rule maps to a different number of plural forms, and doesn’t have any relation with CLDR.

It suffices to say that this fragmentation generated a lot of inconsistencies over the years.

Given the renewed focus on Fluent, last December I started analyzing all Gecko plural forms, to identify inconsistencies between our settings and CLDR. This led to correcting the plural form for 10 languages by aligning with the CLDR values. In a couple of cases, I also reported issues back to CLDR: for Macedonian our ticket was accepted and the changes included, for Latvian it was rejected.

A significant amount of time was also invested in correcting errors in Gecko before starting migrating strings to Fluent: several locales had a wrong number of plural forms, but weren’t aware of the issue, given the hacky nature of plural support in .properties. Starting from January, dashboards are reporting this type of errors, allowing localizers to quickly correct them. Soon, these errors will be reported directly in Pontoon when submitting a new translation.

Work is still underway to fix plurals in other projects in Pontoon, and minimize the impact on localizers: for example, if a string moves from 2 plural forms to 6, you need to invalidate existing translations, and possibly copy over one of the existing values to reduce the need for copy and paste.

Translation of language and region names

Localized names for languages and regions are used in Firefox preferences and other parts of the UI. They’re defined as localizable strings in toolkit, and currently consist of 203 language names and 272 region names.

Since CLDR provides this data as well, the plan is to start using it to localize Firefox UI. This poses a few challenges:

  • Can we replace the current list of country names from GENC with region names from CLDR? This proposal already received a green light.
  • What data is missing from CLDR? We ship languages that are missing from CLDR, we’ll need to file tickets to get those language names added.
  • Since we already have localized names, can we compare them with data from CLDR and see how big the difference is? Strictly related: can the CLDR data be used directly?

Right now, the work is mostly focused on the last point, and tracked in this bug. I started analyzing the difference for a couple of languages, including my own (Italian):

  • 53 language names (26.11%) were translated differently between Mozilla and CLDR. After comparing the two translations for each name to identify the best one, in most cases conflicts were resolved by using the CLDR data. Only seven differences remain after this work (3.45%), with five improvements that need to be reported back to CLDR using their Survey Tool. Two more differences are expected, since they are caused by differences in the English source (Frysian vs Western Frysian, Rundi vs Kirundi).
  • 51 region names were translated differently (18.75%). After, only 11 differences remain (4.04%).
  • Language names are not usable directly: in Mozilla they’re uppercase, since they’re only used as stand-alone labels. In CLDR they’re all lowercase, since the language name is always lowercase when used in the middle of a sentence in Italian.

Analysis is now moving to other languages, with higher percentage of differences. The average difference for language names is 45.49%, while for region names is 30.80%, but we have locales with up to 96% of differences, and we need to figure out why that happens.

The full statistical analysis is available in this spreadsheet. If you’re interested in getting a list of the actual differences for your language, feel free to reach out. One thing to keep in mind is that there are differences for English itself, e.g. “Acoli” vs “Acholi”, or “Caribbean Netherlands” vs “Bonaire, Sint Eustatius, and Saba”, and this inevitably affects the data.

Next steps for 2018

Fluent represents the future of localization for Mozilla products, and it relies heavily on CLDR data. But that’s not the only reason to invest resources in improving the CLDR integration within Firefox:

  • Using CLDR means unifying our approach to internationalization data with the one used in products like Windows, macOS, Android, Twitter, Wikipedia, etc. It also means offering a consistent and more familiar experience to our users.
  • It lowers the burden on our localizers. What’s the point of translating hundreds of strings, if there is an established, high-quality dataset that could be safely reused? This data is a live archive, collected and maintained by a large body of linguistic experts cooperating on CLDR, and exposed on a daily basis to millions of users.
  • We can help extending CLDR support to minority languages that are not relevant for commercial software companies. For example, Firefox Nightly currently ships in 101 languages. While Microsoft covers about the same number of languages through Windows language packs, other browsers support half that number (or less).

As already seen, some parts of UI already use CLDR data: if a locale is not available in the CLDR repository, it won’t have a localized datetime picker, or properly localized dates, and it won’t pick the right plural form when using Fluent strings.

In the coming months we’re going to invest resources on building a pathway for locales to be included as seed locales in CLDR: it will likely be a stand-alone project in Pontoon, with Fluent as storage format, used to collect information that will be converted and used to bootstrap locale data in CLDR. Kekoa, who will be back as a intern in the summer, will contribute to this project (among other things).

We also plan to extend mozIntl API to provide localized language and region names. The current idea is to generate a local data source from CLDR, and integrate it with our own data for locales that are not yet available in the CLDR repository. In order to do that, we need to keep investigating the differences between our current translations and CLDR, and identify potential issues before fully switching to CLDR as source for this data.

Improving consistency of translations and other novelties in Pontoon

Matjaž Horvat

No responses yet

Over the last couple of months several improvements landed in Pontoon. Let’s have a look at some of them!

Translate across projects

Pontoon now allows you to translate strings across all projects in a single translation interface. Select All Projects from the project menu and all the strings being translated to your language will show up in the sidebar.

Select All Projects from the project menu

Select All Projects from the project menu

Many users have expressed interest in such feature, which helps you work on all untranslated strings in one go, or review all pending suggestions submitted by your team contributors. It’s particularly handy when working on consistency: you can now easily search for inconsistencies in your Firefox Desktop and Firefox for Android translations for example.

Search word by word

We’re changing the default search behaviour to search for each word separately and show results that contain all of them. That’s closer to the default behaviour of search engines.

Example: beta firefox
Finds strings that contain Firefox Beta.

To search for exact matches of multiple words, you need to wrap them in double quotes ("). If you wrap the entire string, the search behaviour is the same as in the past.

Example: Open "New Window"
Finds string Open in a New Window.

If you want to search for strings that contain double quotes, you can escape them with a backslash (\).

Example: <a href="%(url)s">
Searches for <a, href=, %(url)s and >.

Example: <a href="\"%(url)s\"">
Searches for <a and href="%(url)s">.

Thanks to Vishal Sharma for contributing this and many other features over the last few months! One of them is also the ability to see the size of a project when requesting it.

Number of strings for requested projects

Number of strings for requested projects

Language-independent links to translate view

Pontoon now has the ability to link to the translate view without specifying the locale. It means that you might encounter links like https://pontoon.mozilla.org/projects/firefox/all-resources/ in project announcements, which will redirect you to the translate view for the “right” locale – guessed from your user and browser settings.

Thanks to Mai Truong for contributing the patch!

Changing your email address

Finally, Pontoon allows you to change your email address! Simply go to your settings page, type in your new email address and log in with a new one.

Thanks to karabellyj for contributing the patch!

What’s coming up next?

We have a few other interesting bits in the oven:

  • Tags (AKA string tiers) will help with organizing strings by priority.
  • Unreviewed suggestions will be made accessible from dashboards.
  • Compare locales checks known from l10n.mozilla.org will be integrated into the translate process. Afterwards, errors and warnings will be displayed on dashboards. Thumbs up to Jarek for turning this long awaited feature into a reality!

Stay tuned for more updates and feel welcome to join the Pontoon community!

Fluent in Gecko, new Pontoon UI, centralized terminology resources, and community workshops in 2018

Jeff Beatty

1 response

In 2017, teams across Mozilla began using the OKR (Objective, Key Result) goal setting framework, including the l10n team. At the beginning of last year, we wrote a post about the OKR goals for l10n, particularly focusing on the impact of Firefox Quantum on l10n work during the year. Being very focused on supporting the Firefox Quantum release at the end of last year, our planning for this year began much later. While we may not have a Quantum-level release this year, we have a lot of reasons to be excited about l10n and many diverse opportunities for community to be involved!

Fluent migration in Firefox

We’ve talked about it for nearly a decade, but we’ve never been in a better position to migrate Firefox to the Fluent l10n system than we’re in right now. If you’re not yet familiar with Fluent, it is a run-time l10n system by Mozilla. Fluent enables us to do a lot of cool things, for example:

  • Localizers can provide dynamic and more natural translations for UI strings,
  • Fluent can substitute missing translations in a user’s language for a translation in another preferred non-English language (i.e., language fallback),
  • Localization updates can be sent to users outside of the official release cycle (i.e., less time for bug fixes to ship).

Beginning with Preferences, Firefox will be migrated to Fluent. This is a dependency of a few other Firefox engineering projects and we’re excited to have the support of the Firefox team to accomplish this. With Fluent in place, we’ll also be able to add cool features like on-the-fly language switching to the browser (aka, multilingual Firefox). Expect to see the browser transform into a linguistically more dynamic product, more capable of meeting the needs of a multilingual global user base.

New Pontoon features

Pontoon’s translate view will receive its first full refresh in five years! Included in that refresh will be a localizeable UI, a rich editor for Fluent strings, workflows for a review/translate feedback loop, and (potentially) themes.

Additionally, Pontoon will see a better string organization system for Firefox. Using the string tiers concept from last year, we have classified strings as being high or low priority based on user visibility and target audience. With this in place, localizers will be able to make more consistent decisions about what to localize and what not to localize for Firefox and how to best spend their limited available time.

Finally, concerning l10n quality, Pontoon will incorporate compare-locales checks, allowing it to do QA checks on translations on-the-fly rather than waiting until they hit the repository. We will also add terminology management and suggestion features.

Centralized language resources

Last year, we made a lot of good progress on centralizing localization style guides and creating a basic terminology database (i.e., termbase). This year, we’re enlisting the help of the SUMO, MDN, and UX teams to create a process for identifying and defining new terms for the termbase and merging all language-specific style guides from all areas of Mozilla into one, central location. We’re also working with the Legal, Creative, and Product Management teams to define an updated policy for translating Mozilla brand and product names, storing data about this policy within the centralized termbase.

Continuous localization for more Mozilla projects

With the success of cross-channel for Firefox desktop and Fennec, we’re looking to expand continuous localization to more projects. The idea behind continuous localization is to unblock the string supply chain. In other words, source strings are made available to localize as quickly as possible, and target strings are used in projects as quickly as possible, creating a continuous “green light” status for source and target strings.

To do this, we need to centralize our localization infrastructure into one place. This means eliminating multiple, redundant dashboards as well as expanding compare-locales to run QA on all project types. This foundation will enable us to perform more automated tasks within the string supply chain and QA processes in the future.

Standardize l10n community roles

With the help of the Open Innovation team, we’re exploring how to standardize l10n community roles. Over the years, the lack of clarity in l10n community roles has led to a number of conflicts and problems, among them:

  • Localizers placed in roles they didn’t ask to be in (e.g., leadership roles),
  • Unclear or un-navigable project ownership or role advancement processes,
  • Misaligned expectations between localizers and l10n-drivers about role-specific responsibilities,
  • Unclear responsibility for feedback and mentorship of new contributors,
  • Community Participation Guideline violations brought on by the stress of the problems listed above (e.g., arbitrary gatekeeping, hostile behavior, etc.).

We’ve initiated a pilot project to co-create l10n community roles with the community, starting with a subset of locales and expanding to larger sets over time. It’s critical to us to have the community’s buy-in, so we plan to involve localizers along the way.

Community workshops

Last, but not least, community workshops.

From 2014-2017, the l10n-drivers assumed responsibility for organizing localization sprints, hackathons, and workshops. We went from hyper-local meetups to large-scale meetups (in Berlin’s workshop last year we had 50+ localizers present). Feedback from the community last year taught us that the format of these workshops had grown stale and localizers desired to have more opportunities to self-organize their own meetups.

With that in mind, we’ve decided to remove ourselves from organizing these meetups this year while preserving the annual budget for these workshops. We’re working with the Mozilla Reps to define a unique process for core localizers to organize their own community meetups. The l10n budget would fund these meetups and the Mozilla Reps process would be used to moderate requests (moderated by l10n-drivers, not Mozilla Reps), make financial transactions, and ensure accountability for money spent. We do not yet have the process defined, but will publish that process in the coming weeks.

We also intend to organize some small, focused l10n meetups. These meetups will be organized around accomplishing a specific task with a small group of localizers. For example, one such meetup that we’re hoping to plan is to test prototypes of the new translate view UI in Pontoon. These meetups will be on an as-needed basis, meaning that we won’t be able to anticipate how many, when, or where these meetups will take place throughout the year. We will, however, make sure the wider community is aware of them as early as possible.

This is a big year for l10n as we work to centralize and automate more of the localization process. We’re very much looking forward to this year being the fulfillment of promises from years past. Thank you to all our community for your help. We’re looking forward to seeing what we can accomplish together as passionate, dedicated Mozillians.