Planet Mozilla L10N

May 31, 2018

Mozilla L10n Blog

The importance of reviewing suggestions

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.

May 31, 2018 10:01 PM

May 23, 2018

Mozilla L10n Blog

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

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.

May 23, 2018 03:29 PM

May 09, 2018

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

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!

Localization impact by the numbers

Snippets

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 09, 2018 09:55 PM

May 08, 2018

Mozilla L10n Blog

Making it hard to break Firefox from Pontoon

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.

May 08, 2018 07:35 PM

May 04, 2018

Mozilla L10n Blog

L10n community events in 2018

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.

With that in mind, we’ve decided to remove ourselves (as much as possible) from organizing these meetups this year while preserving the annual budget for these workshops. We have worked with the Mozilla Reps to define a unique process for core localizers and Resource Reps to organize their own community meetups. The l10n budget (not Reps budget) will fund these meetups and l10n-drivers will review each request on a weekly basis (Tuesdays). With help from the Mozilla Reps we will make needed financial transactions and ensure accountability for money spent. The full process for this is documented in WikiMo here. Included in this process are guidelines for how to best formulate your request, the workflow, and the criteria for attending these events.

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, the first we’re planning is a Firefox Rocket l10n sprint in Indonesia to expand the number of Indonesian languages we ship it in to reach users in rural areas as well as urban centers. 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 very new for us. We’ve done our best to anticipate the various questions or challenges that will arise by organizing events in this way, but I admit that there are likely pieces we’ve overlooked or are unaware of. Please give us feedback throughout the year so that we can improve the process for all involved. We’re looking forward to helping you organize meetups throughout the remainder of the year.

 

 

 

May 04, 2018 02:18 PM

April 26, 2018

Mozilla L10n Blog

Localization Workshop in Kolkata (November 2017)

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:

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.

April 26, 2018 05:01 PM

April 12, 2018

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 community/locales added

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:

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

 

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.

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 12, 2018 07:18 PM

April 10, 2018

Mozilla L10n Blog

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

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

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:

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:

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:

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):

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:

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.

April 10, 2018 06:02 AM

March 30, 2018

Mozilla L10n Blog

Improving consistency of translations and other novelties in Pontoon

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:

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

March 30, 2018 02:11 PM

March 28, 2018

Mozilla L10n Blog

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

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:

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:

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.

March 28, 2018 10:35 AM

March 20, 2018

Mozilla L10n Blog

compare-locales 3.0 – GSOC

There’s something magic about compare-locales 3.0. It comes with Python 3 support.

It took me quite a while to get to it, but the writing is on the wall that I had to add support for Python 3. That’s just been out for 10 years, too. Well, more like 9ish.

We’re testing against Python 2.7, 3.5, and 3.6 now.

Thanks to Emin Mastizada for the reviews of this patch.

Slightly related, we’re having two l10n-tooling related proposals out for this year’s Google Summer of Code. Check out Google’s student guide for how to pick a project. Adrian is mentoring a project to improve the experience of first-time users of Pontoon. I’m mentoring a project to support Android’s localization platform as a first-class citizen. You’d write translation quality checks for compare-locales and add support for the XML dialect to Pontoon.

March 20, 2018 06:54 PM

March 08, 2018

Mozilla L10n Blog

L10n Report: March 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

We enabled several new locales on Pontoon in the past weeks, get in touch if you speak the language and want to contribute:

New content and projects

What’s new or coming up in Firefox desktop

Firefox 59 closed down for localization on February 28, while 60 will remain open until April 25. Firefox 60 is an ESR release, so it’s particularly important to catch up with localization and ensure a good quality in the shipping build.

From a localization point of view, the focus remains on migrating existing Preferences strings to Fluent. We have recently passed the 100 messages milestone, with the migration of the XUL portion of the General pane, and started introducing some of the cool features available in the new localization system.

use-current-pages =
.label =
    { $tabCount ->
        [1] Use Current Page
       *[other] Use Current Pages
}
.accesskey = C

For more details about this migration, see the announcement on dev-l10n. Also make sure to familiarize yourself with both Pontoon’s UI and Fluent syntax.

More migrations are planned for the 61 Nightly cycle, starting on March 12.

Activity Stream (New Tab) is also planning to integrate its settings in Firefox main preferences for 60: new strings have already landed in the Activity Stream project, a few more will land in mozilla-central.

What’s new or coming up in mobile

There’s a lot going on around mobile this month, so hang on tight!

First of all, Firefox for iOS is soon launching it’s v11. L10n deadline for this is Tuesday, March 13th. This release includes many cool new features and improvements, such as:

On the Firefox for Android front, merge day is like for Desktop, so March 12th. The official release is the next day. Locales supported by the Play Store should expect to get an updated string for the What’s New Beta 60 this week. Please remember to check your appstores folder on Pontoon for anything new! 🙂

Firefox for Fire TV v2 is also right around the corner, and the l10n deadline for completion is Mon March 12. Firefox for Fire TV currently supports 8 languages but have no fear – an in-app locale switcher is in the works for future versions. This means we will be able to provide as many languages as we want (well… almost! 😉 ).

Focus for Android is regaining a bit of activity this month, with a few new strings exposed. Something important to note is that the mobile team stopped using Buddybuilds for testing on device. The APKs are on TaskCluster, which will be where you will be heading in order to test your l10n work on (you may need to uninstall your current Buddybuild first though). A v4.1 is expected at the end of the month – more details to come soon.

Focus for iOS continues to be on pause for now. Expect spot releases here and there. As always, stay tuned on the dev-l10n mailing list for any udpates!

On a more or less related topic – Mozilla is participating in the Google Summer of Code project, and we’re looking to mentor students to work on some really cool projects… come check them out (especially the ones related to Pontoon, wink wink)!

What’s new or coming up in web projects

The Common Voice project is Mozilla’s initiative to help teach machines how real people speak. The first time the team that came to speak to the localization communities was the Berlin L10n Workshop last September. The discussion generated a lot of interests and shed some light on the technical challenges as well. There are two parts that made up the project: the web page and the recordings.

Fast forward, the web part of the project is now open to localization. The team has been overwhelmed with enthusiasm and responses. The website is being localized in 17 languages. The project has attracted quite a following. There are new languages added and new contributors introduced to established communities. Thanks to all who helped with onboarding of the new contributors and to our new contributors who join the Mozillian community.

To the locale managers, please review new suggestions and provide constructive feedback to the new localizers in a timely manner. Share glossary and style guide if they are available. Suggest them sign up to web project mailing lists for future updates, and create an account Mozillians.org!

A few words on where the project stands:

What’s new or coming up in Foundation projects

Not a whole lot happening this month on localization on the Foundation side, mostly focusing on collecting feedback from our donors to improve our campaigns and running different campaigns in the U.S.
But the Advocacy team is still prepping up a Copyright push before the JURI vote, which has been delayed once again. And they are also exploring campaign ideas around connected toys that could be launched in certain European markets, but the toys themselves are still being investigated. More to come soon!

What’s new or coming up in Pontoon

In February, a team of Pontoon contributors met in Munich to drill into Translate.Next, our effort at rewriting the translate view of Pontoon and building the foundations of the future of Pontoon as a whole. One of the topics we discussed was how to involve the community in the development of Pontoon more closely. As the first step we created a Pontoon category on Discourse, where we’re hoping to get feedback on proposed developments as well as ideation and problem reports.

Additional way to review localized emails

Reviewing Mozilla localized emails can be challenging, especially when you can’t easily display all the strings at once, strip the HTML code and read it in a format close to what will be sent to subscribers.

Sometimes, inconsistencies or typos are hard to notice before receiving an actual test send proof. While it’s still possible to fix them at this point, it’s much more error prone and requires further edits. And usually, only major issues can be fixed.

This new review mode aims to provide a quick preview of localized emails, even if it can’t replicate everything from the final email template, and does not intent to replace a final review and approval of the test send.

Once you’re done with a first translation, you can proofread the email in its entirety, and adjust your translation if necessary. Translations are pulled automatically from Git every 15 minutes.

If you want to quickly check the source of a string, just hover your cursor over the translation, the English string will appear in a tooltip.

How do I access the review mode?

Simply open this page (also linked in the Engagement project info on Pontoon), find the file you just translated then click the REVIEW button. You can use the top menu to jump to your locale.

We hope you will find it handy! And if not, let us know how we can improve it.

Newly published localizer facing documentation

This was mentioned last month, but it’s always good to have a reminder. Come check out what Kekoa (our l10n intern from last summer) wrote out to help l10n communities (yes, that’s YOU!) write simple – but thorough – style guides.

Make sure to start out by reading the Mozilla General Style Guide first, since it provides the basic guidelines for translating Mozilla products. This guide should be used in coordination with a locale-specific style guide for your language.

Then look at some general guidelines that will help you create your own locale style guide.

We encourage communities to participate actively and create or modify their existing style guides here. Everything is explained in the documentation above, so don’t be shy and give it a try! (or ask anyone from l10n-drivers to help out if you’re not sure how to proceed).

Now, are you interested in learning more about Fluent from a localizer perspective? Then this is just what you need!

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.

March 08, 2018 05:33 PM

March 01, 2018

Mozilla L10n Blog

Firefox Nightlies

We’ve run into a problem with localized Firefox Nightlies in some languages today. We’d like to apologize for that, and also help you getting unstuck.

The Nightly builds of Firefox from February 28 in some localizations listed below start with an XML parsing error, the infamous YSOD – the yellow screen of death. To fix your local installation, either go to the Nightly Download Page and reinstall Firefox Nightly, or run the following in your Firefox install location:

firefox.exe -chrome chrome://browser/content/aboutDialog.xul

The latter should just launch the about window, and download an update for Firefox Nightly. You might need to adjust the executable name, depending on your platform. The example above is for Windows.

The affected localizations are: as, bn-BD, bn-IN, en-GB, en-ZA, es-ES, gn, gu-IN, hi-IN, ia, ja, kn, ko, mai, mr, my, ne-NP, or, pa-IN, si, te, zh-CN, and zh-TW.

Please don’t blame the localizers for this, whether a localization was affected or not depended on technical details.

Check out bug 1442145 for those technical details and more, and bug 1442181 on how we intend to avoid this problem in the future.

March 01, 2018 06:21 PM

February 15, 2018

Mozilla L10n Blog

Leadership shared agreements and localization

Cross-posted from Discourse. If you have comments, please join the discussion there.

A few days ago the Open Innovation team wrote two posts about the general direction of Mission Driven Mozillians and the Revised Leadership Principles – now titled “Shared Agreements”.

The number one biggest question we hear anytime we talk about the shared agreements is “But what will implementing these agreements actually look like? How are we going to do this?!”.

Understanding how these ideas start can positively shape and influence the way Mozilla communities function is primary goal of this work in 2018. By partnering with specific teams and communities to run pilots the Open Innovation team will create processes and support systems that will ultimately make it possible for every Mission Driven Mozillian to make these ideals a reality.

To start (in this first quarter) Open Innovation will be working with the L10n-drivers Team piloting an experiment on how we can implement these agreements into the functioning of specific L10N communities by finding implementations that advance community health with respect for the uniqueness of each.

The goals of this pilot are:

The staff supporting this pilot: Jeff (@jbeatty), Delphine (@Delphine), Peiying (@pmo), Emma (@emma_irwin), Flod (@flod), Theo (@theo) and Ruben (@nukeador).

Don’t Wait! While we start working with pilot communities in Q1 we hope that all Mozillians start having conversations about the agreements including what changes might be required to make to roles and structures in make your community healthier and more inclusive. This is something that the #reps program has already started doing.

February 15, 2018 07:33 PM

February 07, 2018

Mozilla L10n Blog

L10N Report: February 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

Migration to FTL (Fluent)

In the past releases we reached a few small but important milestones for the Fluent project:

For Firefox 60, currently in Nightly, we aim to migrate as many strings as possible to Fluent for Firefox Preferences. The process for these migrations is detailed in this email to dev-l10n, and there are currently 2 patches almost ready to land, while a larger one for the General pane is in progress.

While Pontoon’s documentation already had a section dedicated to Fluent, constantly updated as the interface evolves, our documentation now has a section dedicated to Fluent for localizers, explaining the basic syntax and some of the specific features available in Gecko.

Plural forms

We already talked about plurals in the December report. The good news is that strings using the wrong number of plural forms are now reported on the l10n dashboard (example). Here’s a summary of all you need to know about plurals.

How plurals work in .properties files
Plural forms in Firefox and Firefox for Android are obtained using a hack on top of .properties files (plural forms are separated by a semicolon). For example:

#1 tab has arrived from #2;#1 tabs have arrived from #2

English has 2 plural forms, one for singular, and one for all other numbers. The situation is much more complex for other languages, reaching up to 5 or 6 plural forms. In Russian the same string has 3 forms, each one separated from the other by a semicolon:

С #2 получена #1 вкладка;С #2 получено #1 вкладки;С #2 получено #1 вкладок

The semicolon is a separator, not a standard punctuation element:

Edge cases
Sometimes English only has one form, because the string is used for cases where the number is always bigger than 1.

;Close #1 tabs

Note that this string has still two plural forms, the first form (used for case ‘1’, or singular in English) is empty. That’s why the string starts with a semicolon. If your locale only has 1 form, you should drop the leading semicolon.

In other cases, the variable is indicated only in the second form:

Close one tab;Close #1 tabs

If your locale only has 1 form, or use the first case for more than ‘1’, use the second sentence as reference for your translation.

There are also cases of “poor” plural forms, where the plural is actually used as a replacement for logic, like “1 vs many”. These are bugs, and should be fixed. For example, this string was fixed in Firefox 59 (bug 658191).

Known limitations
Plurals form in Gecko are supported only in .properties files, and JavaScript code (not C++).

What about devtools?
If your locale has more plural forms than English, and you’re copying and pasting English into DevTools strings, the l10n dashboard will show warnings.

You can ignore them, as there’s no way to exclude locales from DevTools, or fix them by creating the expected number of plural forms by copying the English text as many times as needed.

Future of plurals
With Fluent, plurals become much more flexible, allowing locales to create special cases beyond the number of forms expected for their language.

What’s new or coming up in mobile

You might have noticed that Focus (iOS/Android) has been on a hiatus since mid-December 2017. That’s because the small mobile team is focusing on Firefox for Amazon Fire TV development at the moment!

We should be kicking things off again some time in mid-February. A firm date is not confirmed yet, but stay tuned on our dev-l10n mailing list for an upcoming announcement!

In the meantime, this means we are not shipping new locales on Focus, and we won’t be generating screenshots until the schedule resumes.

For Firefox on Fire TV – we are still figuring out which locales are officially supported by Amazon, and going to set up the l10n repositories to open it up to Mozilla localizations. There should also a language switcher in the works very soon, too.

Concerning the Firefox for iOS schedule, it’s almost time to kick-off l10n work for v11! Specific dates will be announced shortly – but expect strings to arrive towards the end of the month. March 29 will be the expected release date.

On the Firefox for Android front, we’ve now released v58. With this new version we bring you two new locales: Nepali (ne-NP) and Bengali from Bangladesh (bn-BD)!

We’re also in the process of adding Tagalog (tl), Khmer (km) and Mixteco Yucuhiti (meh) locales to all-locales to start Fennec single-locale builds.

What’s new or coming up in web projects

What’s new or coming up in Foundation projects

Our 2017 fundraising campaign just finished, but we’re already kicking off this year’s campaign.
One area we want to improve is our communication with donors, so starting in February we will send a monthly donor newsletter. This will help us better communicate how donations are put to use, and build a trust relationship with our supporters.
We will also start raising money much earlier. Our first fundraising email will be a fun one for Valentine’s Day.

A quick update on other localized campaigns:

The final countdown has started for the Internet Health Report! The second edition is on its way and should be published in March, this time again in English, German, French and Spanish.

What’s new or coming up in Pontoon

Friends of the Lion

Image by Elio Qoshi

Shout out to Adrien G, aka Alpha, for his continuous dedication to French localization on Pontoon and his great progress! He is now an official team member, and we’re happy to have him take on more responsibilities. Congrats!

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.

February 07, 2018 09:31 PM

December 08, 2017

Mozilla L10n Blog

L10N Report: December 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

New community/locales added

Sicilian (scn), Luxembourgish (lb), and Shuar (jiv) started translating Firefox on Pontoon. If you speak any of those languages, get in touch to help!

While Amharic (am) is not a brand new locale, it has recently known a period of revival. They are going to ship their first localized Mozilla product next week, which is Focus for Android. Congrats!

New content and projects

What’s new or coming up in Firefox desktop

Wondering why there weren’t new strings to translate for Firefox in the past few weeks? We hit a bit of a roadblock with cross-channel and merge day. Axel is working hard on finding a solution, we’re going to resume exposing new strings as soon as possible.

The current queue consists of about 130 strings, most of them belong to the new about:devtools page. This is the first step in decoupling Firefox Developer Tools from the main application, moving them into an add-on that can be disabled on release and beta channels.

We have also uncovered a couple of wide-spread (and long standing) l10n bugs.

PKCS #11 (security)

pipnss.properties has a peculiar set of limitations for a few strings: once encoded to UTF-8, they need to fit a 32 or 64 bytes buffer. Turns out we had 264 errors in our localizations, accumulated over 15 years!

A bug has been filed for each of the 71 affected languages, and within 24 hours we were already under 180 errors. Thanks for the quick response!

Incorrect number of plural forms

Plural forms in Firefox and Firefox for Android are obtained using a hack on top of .properties files (plural forms are separated by a semicolon). For example:

#1 tab has arrived from #2;#1 tabs have arrived from #2

English has 2 plural forms, one for singular, and one for all other numbers. The situation is much more complex for other languages, reaching up to 5 or 6 plural forms.

In Russian the same string has 3 forms, each one separated from the other by a semicolon:

С #2 получена #1 вкладка;С #2 получено #1 вкладки;С #2 получено #1 вкладок

It looks like several languages have an incorrect number of plural forms, or a completely wrong plural rule. You should have seen bugs if your locale is affected, or fixes directly in Pontoon if the mistake was easy to identify (e.g. a closing extra semicolon).

What’s new or coming up in mobile

Did you notice that Firefox iOS v10 came out, with many more languages added? Come check it out here if you haven’t! Languages added are: Afrikaans (af), Bosnian (bs), Spanish Argentina (es-AR), Galician (gl), Armenian (hy-AM), Interlingua (ia), Khmer (km), Kannada (kn), Malayalam (ml), Odia (or), Punjabi (pa-IN) and Sinhala (si).

If you see that your language is incomplete you can get involved and help! Just reach out to Delphine.

Focus iOS and Android should get a new release some time next week! V4 is right around the corner, and will offer a ton of cool new features. If you don’t have Focus yet, you can find the iOS version here and the Android one here. While usually on a two week release schedule, Focus will take some end of year vacations and come back in January. This means Focus localizers will also have some time off too 🙂

What’s new or coming up in web projects

Mozilla.org project is finally taking a break! This is after a few weeks of mad rush leading up to the Firefox Quantum launch to add a few more new pages and revisions. Thanks to all of you who have been part of this journey, keeping the site to date despite the tight schedule! Mozilla.org site has gone through quite a transformation since the release of the new branding guideline. The logos, color schemes and palettes, layout, and navigation menu all went through major changes. Content style and tone had a major shift to correspond to the visual update. Since June, you have localized and reviewed about 10,000 words, in 20+ new, replacement, and updated pages.

During the “quiet” period, there will be some cleanups in the backend, so obsolete pages will be permanently removed from the dashboards. There might be small updates here and there as a result of the cleanup. Keep an eye on the dashboard for these non-urgent changes.

If you are still catching up with the updates, use the webdashboard for pending projects in your locale.

What’s new or coming up in Foundation projects

On the campaigns side, the Foundation is currently focused on the fundraising and the *Privacy Not Included campaigns.

For fundraising, we should be sending 2 or 3 more emails in December, you should see them appear on the webdashboard. Thanks a lot for all the work you’ve already done for fundraising so far, you’ve helped us a lot! We would be in a far worse position without your help.

This week we’ve worked with the snippets and product teams to launch an improved version of the snippets in Firefox Quantum, making them a bit more prominent and adding back the donate form. Hopefully more people will notice your work and donate eventually!

We are also doing some video testing in English and German, kudos to Michael for his quick help.

Newly published localizer facing documentation

A new document is available with basic instructions on how to use Bugzilla for localizers.

Events

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.

Please note that there will be no January l10n report as this is going to be a quiet month (for once) at Mozilla. Happy end of year holidays to those of you that celebrate it!

December 08, 2017 12:42 AM

November 03, 2017

Mozilla L10n Blog

In Memoriam: Mamadou Niang, Fulah localizer

Guest post from Mozilla Fulah community leader, Ibrahima Saar. UPDATE: Added pictures and a PayPal link for donations to the Mamadou’s family.

It is with deep pain that we announce that our friend, teammate Mamadou Niang died in an accident while traveling from rural town Matam to Dakar to attend a workshop at his organization’s headquarters. We had just had a meeting the day before to sprint to our 31st October deadline for Firefox localization. His last words, the morning before he traveled: “Don’t worry, I will be available to work on Pontoon while away.” Mamadou Niang has been working as a Fulah specialist and rural development project coordinator for the organization Tostan (Humanitarian and Literacy). He was the co-organizer of our 2014 workshop in Dakar while also very busy moving around villages on his motorbike. Also Niang was almost the person who took care of many families as he was the only one earning a salary among a large family. He was my friend and mentee and I am so sad.

After the online meeting we had, he told me that he would leave for the town of Thiès the next morning. The city of Thiès is about 500 kilometers from where he worked. Actually Mamadou is from a small village called Aram, on the river Senegal in the far north of the country. Aram is a well-known village because a very famous Fulah singer who invented a new musical genre called “Pekaan” is from there. it is a fisherman’s village where everyone has fishing as a traditional occupation and that occupation is a very important cultural aspect because it consists not only of fishing but all the cultural practices that go with fishing.

That community of villages across the north of Senegal and the south of Mauritania is well known for their knowledge of water and the spirits of the river. If some of you you remember, you might have heard about many Firefox terms derived from the practice of fishing. Terms like “aspect ratio” and “Time Out” are directly derived from that community’s fishing tools and practices. Mamadou and I are both from that community and are also a specialist of the language. That, plus the fact he was working in the field in rural areas, made Mamadou Niang a valuable asset for the Fulah localization team.

On Wednesday, October 25th Mamadou was on a trip to the headquarters of his organization for a workshop. He frequently traveled there on public transport to attend meeting, submit reports, and the like. Last year, he posted on Facebook a photo warning people that the trip from Matam to Dakar was extremely difficult and dangerous and people should be very careful. He also called on the government to repair roads and make them more secure. Sadly, he died in a public transport accident on the same type of vehicle that he posted it on Facebook.

When he left in the morning I told him that we would chat after he’d arrive. He also assured me that he would be available for working on Pontoon while away. The day before we struggled to get him migrate his account from Pootle to Pontoon, since I could not see him on the team list to change his permissions. He had an extremely slow connection and we only succeeded late in the afternoon. Actually, I proposed he translate one string so that I can see him on the list of contributors, which he did. I added him to the Fulah team finally.

I have been mentoring Mamadou Niang for a few years now and I was so happy to see him contribute so much especially on Firefox OS back in 2014. Then he was also very active spreading the word about Firefox because he had first-hand contact with people learning local languages as part of his work for the organization Tostan. In 2014 he was very active helping me recruit people who would participate in the workshop we organized in Dakar, the capital of Senegal from the 3rd to the 6th of March. He was very very valuable to me because most of the people who subsequently participated in the workshop did not know me and there was no way I could get in touch with them. Most of them indeed are working in rural areas where literacy work is the most needed it was the first time to meet him and to meet many of the people who participated in the workshop. Since, we have become very very good friends and we chatted on Facebook or spoke on the phone virtually every day.

Although he was using a very busy traveling across the countryside on his motorbike, he helped a lot with translation work on Pootle. Since we migrated translations to Pontoon, it was his first time to come to the new platform to set up his account and start working. Unfortunately that lasted less than 24 hours.

We will miss Mamadou very much because he was so kind, so helpful to all and always joking. He was also very active in his Village to help with projects on human development as well as literacy. He was a husband and a young father who took care of many families. Therefore he left his family with sorrow and also concerned for the future. May his soul rest in peace.

A fund is being raised for Mamadou Niang’s family. If you are interested in contributing, please visit PayPal.

November 03, 2017 02:34 PM

November 01, 2017

Mozilla L10n Blog

L10N Report: November 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

Today was the deadline to ship localization updates in Firefox Quantum (57). All translations added from now on in Pontoon will be shipping in Firefox 58.

Last week we made Form Autofill available for localization as part of the Firefox project on Pontoon. Currently it consists of 66 strings, and testing instructions are available in this document.

Talking about testing Firefox Desktop, take a look at the new QA view in Transvision to check keyboard shortcuts.

What’s new or coming up in Test Pilot

A lot of obsolete strings (65) have been finally removed from the Test Pilot website. This should make it easier for new locales that want to pick up this project for localization.

What’s new or coming up in mobile

As for desktop, today was the last day to get in your strings to ship localization updates in v57. All translations added from now on in Pontoon will be shipping in Firefox Android 58.

Firefox iOS v10 l10n deadline is today as well, both for localizing and testing your work. Friendly reminder that St3fan is from now on generating daily screenshots, which means once you’ve translated in Pontoon, you can check your work on the screenshots the next day! Come check them out here: https://wopr.norad.org/~fxios/

This is a truly useful feature that you should take advantage of, especially if you don’t have an iOS device to check your work on. A big thanks to St3fan for automating these daily and improving the general experience of testing!

Sneak peak: many cool new features are coming up with this v10! Amongst other things, the Firefox team has been focusing on Photon, New Tab and iOS 11 compatibility with iPhone X, Face ID, and drag and drop support for iPad.

If you want to try out the v10 Beta, it has been available since Friday Oct 27. Sign-up here: https://www.mozilla.org/en-US/firefox/ios/testflight

Don’t be shy: file bugs, suggest features, and help make Firefox iOS overall one of the best mobile browsers out there!

Focus Android and iOS are currently in the testing phase for Granite version (l10n deadline for testing and screens is next Tues, Nov 7th). The screenshots are updated for both, please let us know if you have any questions or concerns:

And as usual, don’t be shy and file any bugs if you find issues, or request feature improvements if you have any! If you want to be added to the test builds, you can reach out to Delphine. Also, Focus for Android is available as a beta on the Play Store here.

What’s new or coming up in web projects

There are quite a few updates and new pages added to www.mozilla.org on a weekly basis for more than a month. This surge of change and new content should subside as we are closer to launch date. Thanks to you all for your timely responses and questions.

The new Firefox landing page comes in two versions. The longer version, which is in the form of CEO’s letter, will be available in 12 locales. For those who are impacted by the late decision and timing of the finalized content, thanks to your dedication to address these localization requests at this late stage before a major launch.

For Mobile, we have locale specific requests for id (Firefox Rocket) and zh-TW. A new type of project called Mobile Contextual Hints create challenges for the select locales, as localizers must find creative ways to fit localized content in a tight space.

For the monthly email request from marketing team, we are making progress in convincing the team to move the project to Pontoon and communication through bugzilla, instead of individual emails.

What’s new or coming up in Foundation projects

The IoT survey results have been published! It will be promoted via various channel in the next days, but you can be amongst the first people to read it here. It’s great to see the diversity of respondents being represented in the report. And if you speak Spanish, in addition to our localized blog post, Univision published an article as well.

Also keep in mind that we’ve started ramping up our traditional fundraising campaign, now is a good time to complete the website translations and make sure everything looks good on the website. You might see a few edits to the website as we might try new experiments or land small improvements, or a few snippets to translate, but it shouldn’t be a lot of content. The main content that has yet to come is the fundraising emails (about 4 of them), they should all be ready mid-November and will target French, German, Spanish and Brazilian Portuguese in December. Stay tuned!

In terms of timing, the campaign will be quiet for the second half of November, to leave all the space to Quantum, then will ramp up again from the end of November and until December 31st.

Events

Opportunities

We are still looking for an l10n intern next summer (“Community Localization Analyst”). You can apply here: https://careers.mozilla.org/position/gh/838751

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)!

Sad News

It is with great sadness that we are announcing that our Fulah localizer and friend Mamadou Niang has passed away last week. He will be missed and we’ll have more to share about this tragic matter in a subsequent blog post.

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.

November 01, 2017 10:47 PM

October 11, 2017

Mozilla L10n Blog

L10n Report: October 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

Firefox 57 is now in Beta. The deadline to get your localization updates into release is November 1st, please make sure to catch up with missing strings (if you need) and get as many eyes as possible on the versions of Firefox localized in your language.

On a positive note, now that cross-channel is ready and running, you only have to translate strings once for both Nightly and Beta.

Going into localization details: we’ll soon start localizing the Form Autofill system add-on, while we’re studying how to expose strings for about:studies.

Nepali (ne-NP), after a bit of a pause, is trying to ride the release train with 58: if you speak the language, download the Nightly build and help them finding and fixing issues.

Do you speak Assamese, Interlingua, Lao, Latgalian, Maithili, Malayalam, or Tagalog and want to help? Read this blog post.

What’s new or coming up in mobile

Focus iOS and Focus Android are not only now following a bi-weekly release cadence – but the releases are finally synced! Check out the Focus iOS release schedule, as well as the Focus Android one, for more specific details. Note that we do not put the l10n deadlines in Pontoon anymore, given we would have to change them every two weeks.

Firefox iOS strings for v10 strings should be coming shortly. There will be some great improvements with the v10, so stayed tuned on the dev-l10n mailing list to know when that happens (l10n deadline will also be entered in Pontoon)!

On a related note: have you noticed that Firefox iOS v9 now has Tracking Protection turned on by default for Private Browsing mode – and can easily be enabled for normal mode? It was one of the most requested features, and was therefore implemented. Firefox iOS 9.0 also provides improved bookmarks synchronization across devices. It makes the sync functionality – updating passwords, history and bookmarks between mobile and desktop – better and seamless.

On the Focus Android side, there are now multiple tabs! More information about the new Firefox iOS and Focus Android features can be found here. You can also join the public beta for Focus on Android channel on the Google Play Store now. Setup auto-update in the Google Play store to automatically get a new beta version once it’s available. More details here.

And last but not least, there’s a new mobile project targeting Indonesia, called Firefox Rocket. The soft launch was Monday, and it was released as a public beta. It is an experimental fast and lightweight browser made for the needs of emerging markets. The actual launch is targeted some time in November. If you are not in Indonesia, you can try out the app via the apk here.

As you can see, many of our projects are not only growing and improving – more and more new ones are created as well! As part of this ongoing growth, we’d also like to expand the number of localizations that we ship on mobile. As a first step in this direction, we’d like to invite anyone speaking Swahili or Amharic to come join the localization effort. Feel free to contact Delphine about this if you’re interested!

What’s new or coming up in web projects

[Mozilla.org]: Thanks to all the communities for working hard to clear the web project dashboard. The anticipated new and updated pages will be coming your way on a weekly basis in the next few weeks. Keep an eye on the mailing list and always refer to the web dashboard for pending tasks.

[Marketing]: Firefox Rocket campaign messages written for the Indonesian market were prepared and localized by a local marketing agency. Huge thanks to the Indonesian community who was involved in reviewing and revising the campaign messages.

[Engagement]: Expect requests for the monthly snippets and emails in the default language sets in the weeks leading up to Firefox Quantum launch. Also the monthly email content is now staged in Pontoon for localization. If your community wants to move this project from spreadsheet to Pontoon, let us know!

[Legal]:

What’s new or coming up in Foundation projects

We are happy to report some nice improvements to the donate experience, we’ve finally added support for SEPA donations! And we also removed fees for checks in foreign currencies. All that for both donations to Mozilla Foundation and Thunderbird. We expect this to have a positive impact on donation, and to lower frustration of our donors. We’ve updated the FAQs and donation instructions, so if your locale is not complete for the Fundraising project, help us reach 100% before our big push over the next weeks!

Next steps for fundraising are tweaking our snippets (a longer copy test should be starting really soon), then localizing emails starting mid-November that should be sent at the end of November and until the end of the year.

After several schedule changes at the European Parliament, the Copyright campaign is kicking off again this week.

We’ve got great findings to report after analyzing the (many) responses to the IoT survey launched in August. If you want to be among the first people to read them, help us localize our report in German, Spanish, French, Italian or Brazilian Portuguese!

We are also working in the U.S. with Univision on a holiday guide in English and Spanish featuring product reviews (of toys, game systems, fitness trackers, home assistants, smart TVs, and more) written by experts in our network. The main goal is to help people make educated choices, taking privacy & security into consideration before buying new connected devices.

Finally, MozFest is starting in a few days in London! If you’re attending, you may run into Théo. Say hi!

What’s new or coming up in Pontoon

As of the last week of September Pontoon exposes data about projects and locales through a publicly available API. Read more about it in the blog post. If you’re interested in the planning process of the upcoming milestones refer to the L10n:Pontoon/API wikipage.

We’ve also landed several optimizations; searching for strings is now 60% faster and we’ve also improved load times of various pages:

What’s new or coming up in Transvision

In the next few days, Transvision will support cross-channel for Gecko-based products, this means you will be able to search for strings in Beta and Nightly from a single place (and Release as soon as 57 is released).

We are also adding support for Focus for iOS and Android! There will also be some minor improvements, stay tuned.

Newly published localizer facing documentation

Several documents have been published over the last month, check them out!

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.

October 11, 2017 07:00 PM

October 10, 2017

Mozilla L10n Blog

Exposing Pontoon Data Through API

Application Programming Interface, or API for short, is how computer programs talk to each other. As of the last week of September Pontoon exposes data about projects and locales through a publicly available API.

In this first iteration we focused on one use-case outlined in bug 1302053.

It would be really useful being able to retrieve information from Pontoon via API. Interesting queries:

  • Stats for a locale: supported projects, status of each project.
  • Stats for a project: supported locales, incomplete locales, complete locales.

After a thorough discussion and research we settled on using GraphQL. GraphQL is both a language for describing the API queries and a runtime for running these queries against the real data. It was created by Facebook and has lately seen a lot of adoption due to its declarative nature, predictability of results and the GraphiQL IDE which allows to easily explore the API and test different queries in the browser.

With GraphQL, the users of the API have precise control over the data the API returns. In the following example, the API will return a list of all active projects and for each project listed only its name will be retrieved.

query {
    projects {
        name
    }
}

It’s also easy to query data spanning multiple relations in the data model. In the following example for every active project the API will also return a list of locales for which the project has been enabled.

query {
    projects {
        name
        localizations {
            locale {
                name
            }
        }
    }
}

Queries can be made using GET and POST requests alike. Here are a few real-life examples which illustrate what’s already possible in the current version of the API:

In an effort to make it easy to get started with the API and make the available data discoverable, the first milestone of the API ships with the GraphiQL IDE. GraphiQL is a query editor which runs in the browser. You can use it to explore the API and test queries in the browser. Currently it’s only available in local deployments of Pontoon at http://localhost:8000/graphql. In the future we plan to enable it on production as well.

 

The end goal is to expose almost all data that Pontoon stores and processes: translations and suggestions, contributors’ activity, notifications and others.  Ultimately the API will also allow writing to the database and will become the back-end for the future versions of Pontoon. We’d like to keep the development of the API use-case-driven. If you’re interested in creating a report or an extension which pulls data from Pontoon please let us know about your use-case! We’d like to prioritize the upcoming features to best serve the needs of the community. Refer to the L10n:Pontoon/API wikipage for more information about the planning process.

October 10, 2017 03:52 PM

October 05, 2017

Mozilla L10n Blog

Do you speak Assamese, Interlingua, Lao, Latgalian, Maithili, Malayalam, Nepali, Tagalog? Mozilla needs your help

Firefox 56 for desktop ships in 96 languages, with 5 more only available in the Nightly channel. To give you an idea of what this number represents, while getting the exact list of languages shipping in competitors is really hard, it’s roughly twice the number of languages shipping in Google Chrome, and over 3 times the number of localizations available in Apple Safari.

That’s possible thanks to the incredible work of our Community, since Firefox localizations are maintained by contributors, coordinated by a handful of employees (aka localization drivers).

Unfortunately, there comes a time in the life cycle of a localization when contributions stall: life gets in the way, priorities shift, and there’s no more time to dedicate to Mozilla and localization. As localization drivers, we usually try to identify new community owners, and facilitate the transition process, but that’s not always possible. In some cases, we need to remove a localization, because the amount of untranslated or mixed content reaches a point where the experience for users is simply not good enough.

There are currently 3 languages close to being removed:

They’re all available on Pontoon for translation: if you want to contribute to these localizations, please get in touch with us via our mailing list or #l10n o IRC. If you know people that might be interested, or you are part of the larger localization community, please share this message with your social contacts 😉

Five languages are currently available in Nightly, and they’d welcome help reaching completion or testing their builds:

All Nightly builds for these languages can be downloaded from this page. If you’re interested in helping, feel free to reach out to the respective teams.

October 05, 2017 03:13 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

September 07, 2017

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

In the past weeks we’ve added several languages to Pontoon, in particular from the Mozilla Nativo project:

We’ve also started localizing Firefox in Interlingua (ia), while Shuar (jiv) will be added soon for Firefox for Android.

New content and projects

What’s new or coming up in Firefox desktop

A few deadlines are approaching:

Photon in Nightly is almost ready for Firefox 57, only a few small changes need to land for the onboarding experience. Please make sure to test your localization on clean profiles, and ask your friend to test and report bugs like mistranslations, strings not displayed completely in the interface, etc.

What’s new or coming up in Test Pilot

Firefox Send holds the record for the highest number of localizations in the Test Pilot family (with SnoozeTabs), with 38 languages completely translated.

For those interested in more technical details, Pontoon is now committing localizations for the Test Pilot project in a l10n branch. This also means that the DEV server URL has changed. Note that the link is also available in the project resources in Pontoon.

What’s new or coming up in mobile
What’s new or coming up in web projects
What’s new or coming up in Foundation projects
What’s new or coming up in Pontoon

Newly published localizer facing documentation
Events

 

Accomplishments

We would like to share some good results

Responses by country (not locale), for the 32,000 responses to the privacy survey ran by the Advocacy team back in March, localized in French and German:

It was good, but now let’s compare that with the responses by country for our IoT survey How connected are you? that received over 190,000 responses! We can see that the survey performed better in France, Germany and Italy than in the US. Spanish is underrepresented because it’s spread across several countries, but we expect the participation to be similar. These major differences are explained by the fact that we added support for three more languages, and promoted it with snippets in Firefox. This will give us way more diverse results, so thanks for your hard work everyone! This also helped get new people subscribed to our newsletter, which is really important for our advocacy activities, to fuel a movement for a healthier Internet.
The survey results might also be reused by scientists and included in the next edition of the Internet Health Report How cool is that? Stay tuned for the results.

 

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.

 

September 07, 2017 07:30 PM

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

August 13, 2017

Mozilla L10n Blog

L10n Style Guides on GitHub

When we began talking about style guides with localization communities at l10n hackathons, we suggested that the Mozilla Wiki was a good place to temporarily store them, until we could define a more centralized and accessible place for them, and that that place would most likely be GitHub. After a lot of research, we’ve created GitHub repository to host all of the Mozilla translation style guides, including community-specific ones. Any style guide that is referenced on a team’s contact page has been copied as a markdown file into this repository. The repository has been built with Gitbooks and the style guides can be accessed with greater readability and improved search capabilities.

You may be wondering, “If the community style guides are already available and linked on team contact pages, why do we need this GitHub repository?” We understand this confusion and wish to address why the repository exists. 

Recently, MDN underwent a major style and content change. This meant that the General Localization Style Guide that was available on MDN needed to be assessed to determine what changes needed to be made or if MDN was even a good home for it. After considering alternatives and associated questions, such as “what about community-specific style guides”, we decided that we need to build a place easy to find for all style guides. Having this central repository for all style guides makes it easier to locate all of the style guides that have been created by each community. We don’t want the hard work to go to waste, that’s why we want to make these style guides accessible and link to them from the team’s page in Pontoon. This centralized repository helps us make sure we don’t miss any style guides.

Currently, community style guides are hosted on a variety of sources and in a mix of formats. While this is not a problem in itself, these varied formats and sources can make it difficult to locate the style guides. Additionally, some of these sources stop hosting the style guide or the style guide may become obsolete for whatever reason. This is not exclusive to style guides hosted to non-Mozilla sources. The wiki at mozilla.org doesn’t represent a good home for this data, for that reason we have moved the General Localization Style Guide as well. Rather than lose the style guides currently hosted on the Mozilla Wiki, we decided to make copies of these style guides in the centralized GitHub Repository.

These considerations aren’t newas you probably know from the past year’s workshopsbut they present an opportunity for us to make this change that will facilitate quality assurance and accessibility for our translation efforts.

This brings up a few tasks for language communities that have a style guide or would like to add one to the repository:

  1. Please check that your current community style guide is in the repository and that it is correct. It is possible that the style guide that was migrated to the repository is the wrong version or contains some errors from migration. If there are any errors in the style guide, please see number 2.
  2. If you need to update/correct or add a style guide to the repository, please update it in the GitHub repository. GitHub has instructions on how to update a repository. Please follow these instructions to create a pull request. This pull request will be reviewed before being merged to the official style guides repository to try to maintain quality. In addition, each pull request should be reviewed by another member of the community as some of the repository administrators may not speak the language of the style guide. 

If there are any questions regarding the new repository or community style guides, please direct them to Kekoa kriggin@mozilla.com or flod at flodolo@mozilla.com.

August 13, 2017 02:32 PM

August 10, 2017

Mozilla L10n Blog

Making unreviewed suggestions easier to find

Translation review is the vital part of localization. The first step of each review process is to find suggestions that haven’t been reviewed yet. Since this fundamental task can be quite tedious in Pontoon, we’re making it better!

Problem

You can easily filter the so called Suggested strings, which have at least one suggestion, but none of them have been approved yet. Those are definitely suggestions you should review.

But there might be others, which are harder to find.

If a string has an approved translation and a few suggestions, when a new suggestion comes, it’s almost impossible to discover it. You can use the Has Suggestions filter, which lists all strings with at least one suggestion, but you will not be able to distinguish the new suggestion from the already reviewed ones.

To overcome this drawback, you can delete all suggestions that you decide not to approve and then the Has Suggestions filter will only show strings with unreviewed suggestions. But deleting translations in not a good practice if we want to keep translation history and user statistics accurate.

Solution

Today, we’re removing the ability to delete translations and adding the ability to reject them. A translation can be rejected explicitly with a click on the reject icon or as part of a mass action. When a suggestion is approved or an approved translation is submitted, all remaining suggestions automatically become rejected.

The three review states: approved, unreviewed, rejected

The three review states: approved, unreviewed, rejected.

That means we’re effectively splitting translations into 3 groups – approved, unreviewed and rejected, which allows us to introduce the Unreviewed Suggestions filter. This filter finally makes it easy to list all suggestions needing a review.

Important note: To make the filter usable out of the box, all existing suggestions have been automatically rejected if an approved translation was available and approved after the suggestion has been submitted. Without this change, many locales would end up with thousands of unreviewed suggestions.

The final step in making unreviewed suggestions truly discoverable is to show them in dashboards. We’ll fix that as part of bug 1377969. Also, we’ll be updating the documentation soon to reflect these changes.

Adrian

A huge shout-out to Adrian Gaudebert who contributed the patch. Adrian joined the Pontoon team in July and is a long time web developer at Mozilla. He helped with Elmo in the past and most recently worked on Mozilla Crash Reports. We can’t wait to see what inventions he comes up with next!

August 10, 2017 12:22 PM

August 04, 2017

Mozilla L10n Blog

Create a localized build locally

Yesterday we changed the way that you create localized builds on mozilla-central.

This works for developers doing regular builds, as well as developers or localizers without a compile environment. Sadly, users of artifact builds are not supported.

For language packs, a mere

./mach build langpack-de

will work. If you’d rather wish to build a localized package, you’ll want to get the package first. If you’re building yourself, that’s

./mach package

and if you want to get a Nightly build from archive.mozilla.org, just

./mach build wget-en-US

If you want to do that for Firefox for Android, you’ll need to specify which platform you want. Set EN_US_BINARY_URL to the latest-mozilla-central-* path for the binary you want to test.

And then you just

./mach build installers-fr

That’ll take care about getting the french l10n repository, and do all the necessary things to get you a nice little installer/package in dist. Pick your favorite language from our repositories. Care for a RTL build? ./mach installers-fa will get you a Persian one 😉 .

As with other repositories we clone into ~/.mozbuild, you’ll want to update those every now and then. They’re in l10n-central/*, a repository for each language you tried.

Documentation is on firefox-source-docs.rtd, bugs go here. This works for Firefox, Firefox for Android, and Thunderbird.

And now you can safely forget all the things you never wanted to know about localized builds.

August 04, 2017 04:19 PM

August 02, 2017

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!

Important updates

Mozilla’s Pootle instance is closing down on September 1st, we’ll move existing active localizations to Pontoon. Read this blog post if you’re interested in more details.

New content and projects

What’s new or coming up in Firefox desktop

New content to localize for Firefox desktop is mostly focusing around two areas:

While the Onboarding experience will be an ongoing effort, with content updates between versions of Firefox, the reorganization of preferences should be mostly completed (and it was a complex problem to solve). Unfortunately, another consistent change landed right before merge day for preferences, finally bringing some terminology consistency (website vs site).

In the meantime, still a lot of visible changes in the UI are happening in Firefox, as part of the ongoing Photon project.

Activity Stream (the redesigned about:newtab) is currently scheduled to ship in Firefox 57, with some locales tested as an experiment in 56 (A/B study), while Firefox Screenshots is still scheduled to ship with Firefox 55 for all locales (staged rollout during August, with an increasing number of users receiving the feature over time).

What’s new or coming up in Test Pilot

Test Pilot launched 3 new experiments, two of them are localizable in Pontoon.

Notes adds a simple one-page notepad in Firefox sidebar, to store notes while browsing the web.

Firefox Send, on the other hand, is the first stand-alone web service distributed as part of Test Pilot: it’s a website where you can upload a file, encrypt it and obtain a link to share it. Once the file has been downloaded (or within 24 hours), it gets removed from the server. Basically, a one-time, secure file sharing website that will work with any browser, not just Firefox.

The third project, currently available only for English, is called Voice Fill, and lets you talk with search engines (Google, Yahoo, DuckDuckGo), using AI for speech recognition.

What’s new or coming up in mobile

What’s new or coming up in web projects

What’s new or coming up in Foundation projects

What’s new or coming up in Pontoon

Newly published localizer facing documentation

Kekoa – our tireless intern – is working on documenting how to use the translation interface in Pontoon.

Events

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

August 02, 2017 07:12 PM

July 24, 2017

Mozilla L10n Blog

Making a change with Pootle

tl;dr: As of 1 September 2017, Mozilla’s Pootle instance (mozilla.locamotion.org) will be turned off. Between now and then, l10n-drivers will be assisting l10n communities using Pootle in moving all projects over to Pontoon. Pootle’s positive impact in Mozilla’s continued l10n evolution is undeniable and we thank them for all of their contributions throughout the years.

Mozilla’s localization story has evolved over time. While our mission to improve linguistic accessibility on the Web and in the browser space hasn’t changed, the process and tools that help us to accomplish this have changed over the years. Some of us can remember when a Mozilla localizer needed to be skilled in version control systems, Unix commands, text editors, and Bugzilla in order to make an impactful contribution to l10n. Over time (and in many ways thanks to Pootle), it became clear that the technical barrier to entry was actually preventing us from achieving our mission. Beginning with Pootle (Verbatim) and Narro, we set out to lower that barrier through web-based, open source translation management systems. These removed many of the technical requirements on localizers, which in turn led to us being able to ship Firefox in languages that other browsers either couldn’t or simply wouldn’t ship; making Firefox the most localized browser on the market! Thanks to Pootle, we’ve learned that optimizing l10n impact through these tools is critical to our ability to change and adapt to new,  faster development processes taking the Internet and software industries by storm. We created Pontoon to take things further and focus on in-context localization. The demand for that tool became so great that we ended up adding more and more projects to it. Today I’m announcing the next step in our evolution: as of 1 September 2017, all Mozilla l10n communities using Pootle will be migrated to Pontoon and the Mozilla Pootle instance (mozilla.locamotion.org) will be turned off.

Why?

Over the years, we’ve developed a fond relationship with Translate House (the organization behind Pootle), as have many members of the Mozilla l10n community. Nearly five years ago, we entered into a contract agreement with the Translate House team to keep a Mozilla instance of Pootle running, to develop custom features for that instance, and to mentor l10n communities. As l10n has shifted through the Mozilla organization year after year, the l10n team recently found themselves as part of another internal reorganization, right at the moment in which contract renewal was up for discussion. With that reorganization, came new priorities for l10n and a change in budget for the coming year. In the face of those changes, we were unable to renew our contract with Translate House.

What now?

Before 1 September, the l10n-drivers will be proactively contacting l10n communities using Pootle in order to perform project migrations into Pontoon. Moving project-to-project, we’ll start with the locales that we’re currently shipping for a project, then move to those which are in pre-release, and finally those that have seen activity in the last three months. In the process, we’ll look out for any technical unknown unknowns that Pontoon engineers can address to make the transition a positive and seamless one.

There are a few things you can do to make the transition run smoothly:

  1. Log into Pontoon with your Firefox Account. If you don’t already have a Firefox account, please create one.
  2. Process all pending suggestions in your Pootle projects (i.e., bring your community’s suggestion queue down to 0).
  3. Flag issues with Pontoon to the l10n-drivers so that we can triage them and address them in a timely manner. To do this, please file a bug here, or reach out to the l10n-drivers if you’re not yet comfortable with Bugzilla.

We understand that this is a major change to those contributing to Mozilla through Pootle right now. We know that changing tools will make you less productive for a while. We’ll be holding a public community video call to address concerns, frustrations, and questions face-to-face on Thursday, 27 July at 19:00 UTC. You’re all invited to attend. If you can’t attend due to time zones, we’ll record it and publish it on air.mozilla.org. You can submit questions for the call beforehand on this etherpad doc and we’ll talk about them on the call. We’ve also created this FAQ to help answer any outstanding questions. We’ll be adding the questions and answers from the call to this document as well.

Finally, I would like to personally extend my thanks to Translate House. Their impact on open source localization is unmatched and I’ve truly enjoyed the relationships we’ve built with that team. We wish them all the best in their future direction and hope to have opportunities to collaborate and stand together in support of open localization in the future.

July 24, 2017 08:37 PM

July 11, 2017

Mozilla L10n Blog

The Ten Hands

Gaul is entirely occupied by the Romans. Well, not entirely… One small village of indomitable Gauls still holds out against the invaders.

While most of mozilla gathered in San Francisco, a small group of ten hands gathered in a small village in Slovenia.

Matjaz hosted me, Stas, Adrian and Jarek, to work on Pontoon and other aspects of localization infrastructure at Mozilla. Jarek is a volunteer contributor extraordinaire to Pontoon, and we were finally able to have him join us for his first Mozilla gathering. Adrian is taking a break from his work on Socorro, and will take on work on Pontoon, at least for this quarter.

Adrian, Stas and I hadn’t really looked at the Pontoon code base, so this was a great opportunity to get us onboarded. We also had the chance to talk about some of the pros and cons of the basic data models powering Pontoon.

Jarek and Matjaz made great progress on getting errors and warnings from compare-locales hooked up to Pontoon. The PR already has 43 commits, and is shaping up nicely. It’s been good to see that we were able to use compare-locales as is, though we might want to optimize one API. I was able to help here a bit verbally myself. It’s interesting how efficient such 5 minutes can be, compared to our usual roundtrips of a day between work and not, and continents.

Adrian spent quite some time working on a setup of Pontoon on docker-compose. Having done that myself for the l10n automation, I was his tester here. The PR is now ready for review, which is also on me. Promise.

Stas started to experiment with graphene-django to expose a GraphQL API for Pontoon. That was surprisingly easy to get started. It was also surprisingly bad in performance. He’s written down his notes on the wiki, and we’ll reconvene soon on what the next steps should be. And yes, we abused the word “REST” in a lot of different ways during that week.

Stas and I made a lot of progress on support for Fluent in our core infrastructure, adding support for that in compare-locales and elmo. Stas finalized the support for Fluent in compare-locales. I added support for the diff view in elmo, which required a few updates to compare-locales, too. With the work on compare-locales 2.0, I also updated elmo to support both the legacy JSON output as well as the new JSON output from 2.0.

The days were just packed, as they say. We did go out and explore the area, mostly to get food. In a place where the cab driver has a day job, you have to. In a place where you can see three different countries from your porch, that also means you might go through passport control to go to dinner. Hello Croatia and croatian kunas, where dinner prices are not in euros. Last but not least a big Thank You to Eva and Robert from the Cuk Wine House for their hospitality.

The images are by Adrian Gaudebert and licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

July 11, 2017 01:23 PM

July 08, 2017

Mozilla L10n Blog

New 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 and locales added

New content and projects

What’s new or coming up in Firefox desktop

Big changes are coming to Firefox 57, with some of them sneaking up even in 56 (the version currently localized in Nightly, until August 7). The new feature with more significant impact for localization is the new Onboarding experience: it consists of both an Onboarding overlay (a tour displayed by clicking the fox icon in the New tab), and Onboarding notifications, displayed at the bottom of New tab.

If you haven’t seen them yet (we always make sure to tweet the link), we strongly suggest to read the latest news about Photon in the Photon Engineering Newsletter (here’s the latest #8).

On a side note, you should be using Nightly for your daily browsing, it’s exciting (changes every day!) and fundamental to ensure the quality of your localization.

There is a bug on file to stop localizing about:networking, given how small the target is (users debugging network issues) and how obscure some of these strings are.

A final reminder: The deadline to update Firefox Beta is July 25. Remember that Firefox Beta should mainly be used to fix small issues, since new translations added directly to Beta need to be manually added to the Nightly project in your localization tools.

What’s new or coming up in Test Pilot

The new set of experiments, originally planned for July 5, has been moved to July 25. Make also sure to read this mail on dev-l10n if you have issues testing the website on the dev server.

What’s new or coming up in mobile
What’s new or coming up in web projects
What’s new or coming up in Foundation projects
Newly published localizer facing documentation
Events
Opportunities

Accomplishments

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

July 08, 2017 12:08 AM

June 30, 2017

Mozilla L10n Blog

Localization at Mozilla SF All Hands

Hello from sunny Northern California!

This week was Mozilla’s bi-annual All Hands, a gathering that brings Mozilla employees and community together for a week to hack on key Mozilla objectives. This All Hands, the Firefox team (which l10n is a part of) was in “all hands on deck” mode to make significant progress on the upcoming Firefox 57 launch. That being the case it was a bit different and more unstructured than previous All Hands.

Fun concept art by Sean Martell depicting Mozilla building new Firefox in comic book style.

L10n-drivers this week focused on a number of improvements to the localizer experience. Pontoon saw more work dedicated to QA checks, incorporating elements of compare-locales within the platform itself. We made significant progress toward landing l20n in Firefox desktop, enabling multi-locale Firefox desktop builds, and we creating l10n documentation for Pontoon and other elements of the l10n process. We also performed an initial terminology extraction from mozilla.org in order to create a Mozilla-specific termbase. Finally, we made the next version of the “Promote Firefox in your language” community marketing guide (which will be available on GitHub soon for the final feedback round) and the next version of the monthly Mozilla l10n report.

We’re also happy to announce two new communication channels for the global localization community: Facebook and Telegram. Over the years we’ve learned that different communities around the world need different ways to connect online than the more traditional means: mailing lists and IRC. Our Facebook group and Telegram channel will not replace mailing lists and IRC, but will supplement those in the hopes of increasing our reach to all l10n communities world wide and making it easier to promote the community’s contributions to localization. To avoid spammers, we moderate both of these channels, so if you’d like to join either, please reach out to your l10n community leaders (most of them are in one or both of these channels).

We’re all very excited for new Firefox to reach users on localized builds with Firefox 57. If you’re not already using Nightly in your language, please download and help us improve localization coverage of Firefox in your language. Firefox 57 will have some very exciting new features that non-English speakers will absolutely want in their language. We’ll increase messaging about exciting things in Firefox 57 throughout the next couple of months to keep you informed and allow you to start sharing them with your friends and family.

June 30, 2017 09:37 PM

June 17, 2017

Mozilla L10n Blog

Paris Localization Workshop

From May 6th-7th, 42 participants (coincidence? I think not) gathered in the beautiful city of Paris for another successful edition of our l10n workshops. This was one of our larger scale events with a total of twelve localization communities from four continents: Acholi, Fulah, Songhay, Xhosa, Wolof, Azerbaijani, Turkish, Uzbek, Arabic, Persian, Hebrew and Urdu. What a diverse group! This was in fact the broadest geographical coverage in a single l10n event.

Marcia Knous and Pascal Chevrel, both from the Release Management team and working on Firefox Nightly, joined us and held a Nightly workshop on the side with members from the French community – as well as some joint sessions around Project Dawn and Nightly testing updates, that were of equal interest for both our groups present (i.e., L10n and Nightly communities).

Some may have noticed that, this year, our workshops have slowly started to evolve with each iteration. For example, although spectrograms have been a big part of our past workshops and have proved to be very useful, we decided not to do them this time around. With time, we’ve realized they are unfortunately a time constraint, and that we needed to shift our focus a bit (after all, we had been doing these for the past 2 years).

Instead, l10n-drivers present held a Q&A session – which resembled the Mozilla fireside chats in a way. Overall this proved to be very valuable as it lets localizers really get clarifications and dive deeper into whichever topic they are interested in. In fact, we had l10n-drivers from across the board present, which helped this session be broad enough, and technical enough, to interest everyone present.

(picture by Emin Mastizada)

To give an idea, the l10n-drivers at the event were:

Delphine Lebédel: L10n Firefox mobile project manager

Peiying Mo: L10n mozilla.org project manager

Théo Chevalier: Mozilla Foundation l10n project manager

Axel Hecht: L10n tech lead

Francesco Lodolo: L10n Firefox desktop project manager

Drivers also gave short updates on current projects’ status and general Mozilla plans and goals for the year.

(Picture by Christophe Villeneuve)

We also made room for community presentations this time around. Any community who wanted to present their work was welcome to do so. One of these was a presentation about RTL (right-to-left) on mobile. It was great to see the Arabic, Hebrew, Persian and Urdu communities spontaneously pair up and start collaborating not only for this presentation, but during the workshop as a whole.

Ibrahima from the Fulah localization team also gave a presentation on Unicode and UTF-8 from the perspective of his own community, sharing insights and lessons learned from years of diving into the topic.

Communities spent most of the rest of their time on accomplishing the goals they had set themselves for the weekend (goals and general agenda details here).

Thanks to Flore’s (a long time Mozilla contributor) spontaneous initiative, there was even a cultural activity organized, which included walking to the Trocadéro and seeing the beautiful Tour Eiffel – a must when you are in Paris. Led by Flore, participants bravely faced the parisian rain in order to get a breath of fresh air.

Although logistics were somewhat trickier to plan for such a large and diverse group, it was an incredible experience that allowed communities from completely different backgrounds to share insights and tips amongst each other – which, as always, was a beautiful and humbling moment to witness.

Thanks to the community feedback that we always gather from our final survey, we are able to learn and grow – making each edition an improvement over the previous ones, and building upon each event we hold. One take-away from this (and past) event(s) is that we are currently looking into how other organizations make sure that their events are as “food-friendly” – and accessible – to as many people as possible.

We are also tweaking up our format a bit with each workshop we do this year. We have realized that we need change, and that we can improve things much more quickly by being flexible and adapting with each workshop we hold. Communities are different, issues are different, cultures are different. One format does not fit them all! So we are eager to continue exploring this year and reporting back what we have found. And then building upon the lessons we learn with each new event. Maybe tweaking things up to be more like a localization unconference for the next iteration is going to be our next playground…

In any case, it seems to become clearer each time we organize one of these events that community needs diversity, and needs more meet-ups that let them mingle with a larger crowd. Two days may not be enough, especially given we are flying people from so far away. We’ve learned from our surveys that community misses the larger Mozcamp and MozSummit formats: they need to exchange more with like-minded people, from a much more diverse group, in order to strive and progress effectively. Exploring the idea of global localization workshops, with maybe other l10n communities from other open source projects, is one idea we are also currently playing with.

As usual, thoughts and feedback on improvements are always welcome. We want to hear from you! Always feel free to pitch any ideas by reaching out to anyone in our team.

Next up… Paraguay in August! Stay tuned 🙂

(Picture by Christophe Villeneuve)

(Picture by Christophe Villeneuve)

(Picture by Christophe Villeneuve)

June 17, 2017 12:25 AM

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

September 23, 2016

Mitchell Baker

Living with Diverse Perspectives

Diversity and Inclusion is more than having people of different demographics in a group.  It is also about having the resulting diversity of perspectives included in the decision-making and action of the group in a fundamental way.

I’ve had this experience lately, and it demonstrated to me both why it can be hard and why it’s so important.  I’ve been working on a project where I’m the individual contributor doing the bulk of the work. This isn’t because there’s a big problem or conflict; instead it’s something I feel needs my personal touch. Once the project is complete, I’m happy to describe it with specifics. For now, I’ll describe it generally.

There’s a decision to be made.  I connected with the person I most wanted to be comfortable with the idea to make sure it sounded good.  I checked with our outside attorney just in case there was something I should know.  I checked with the group of people who are most closely affected and would lead the decision and implementation if we proceed. I received lots of positive response.

Then one last person checked in with me from my first level of vetting and spoke up.  He’s sorry for the delay, etc but has concerns.  He wants us to explore a bunch of different options before deciding if we’ll go forward at all, and if so how.

At first I had that sinking feeling of “Oh bother, look at this.  I am so sure we should do this and now there’s all this extra work and time and maybe change. Ugh!”  I got up and walked around a bit and did a few thing that put me in a positive frame of mind.  Then I realized — we had added this person to the group for two reasons.  One, he’s awesome — both creative and effective. Second, he has a different perspective.  We say we value that different perspective. We often seek out his opinion precisely because of that perspective.

This is the first time his perspective has pushed me to do more, or to do something differently, or perhaps even prevent me from something that I think I want to do.  So this is the first time the different perspective is doing more than reinforcing what seemed right to me.

That lead me to think “OK, got to love those different perspectives” a little ruefully.  But as I’ve been thinking about it I’ve come to internalize the value and to appreciate this perspective.  I expect the end result will be more deeply thought out than I had planned.  And it will take me longer to get there.  But the end result will have investigated some key assumptions I started with.  It will be better thought out, and better able to respond to challenges. It will be stronger.

I still can’t say I’m looking forward to the extra work.  But I am looking forward to a decision that has a much stronger foundation.  And I’m looking forward to the extra learning I’ll be doing, which I believe will bring ongoing value beyond this particular project.

I want to build Mozilla into an example of what a trustworthy organization looks like.  I also want to build Mozilla so that it reflects experience from our global community and isn’t living in a geographic or demographic bubble.  Having great people be part of a diverse Mozilla is part of that.  Creating a welcoming environment that promotes the expression and positive reaction to different perspectives is also key.  As we learn more and more about how to do this we will strengthen the ways we express our values in action and strengthen our overall effectiveness.

September 23, 2016 09:19 PM

September 02, 2016

Mitchell Baker

Guest Post: Increasing the Level of Participation in the Hiring Process

This is a guest blog post from Jane Finette, Executive Program Manager, who works closely with me in Office of the Chair.

In a recent blog post Mitchell described why she has been eager to see the hiring process at Mozilla have a larger focus on cross-functional participation, particularly for senior leaders whom we expect to represent a broad swath of Mozilla.  Enabling wider participation in how we hire for leadership has been our starting point.  She notes we began organizing panel discussions for a broader set of people to talk to the candidate some time ago.

The need to hire for a new senior role, Vice President of Marketing Communications, presented an opportunity to further explore this new type of approach. Jascha Kaykas-Wolff, our CMO and the hiring manager for this role, and I sat down to plan and document some further experiments with the hiring process for this role. Our goal from the start was to explore two outcomes: an increased participation within the organization and the simultaneous creation of a meaningful process for candidates to evaluate us.

Enabling participation in the hiring process for the VP of MarComm position was particularly crucial because this person has a role that represents and communicates publicly about a broad swath of Mozilla. The VP of MarComms oversees the global communications, social media, user support and content marketing teams and works across the organization to develop impactful outbound communications for Mozilla and Firefox products.

Jascha's quote Participation in Hiring

What was the process?

Jascha and I designed the interview process right at the start with participation as one of the key objectives. Together we identified interviewers as peers, direct reports, expertise leaders and others who were not from the group where the candidate would work; in this case Marketing.  We identified cross functional areas the hire would interact with on a regular and a geographic basis, these were people who might not otherwise have been part of the interview process.

Here is an overview of the process we devised:

1st round: Peers (no direct reports).
Purpose: Interviewing for values match, strong competency in area of expertise.

2nd round: Directs report + leaders in area of expertise, including cross-functional areas.
Purpose: Interviewing for leadership attributes, values match, competency in area of expertise.

3rd round: Panel – including moderator and panel members who were not part of the group where the candidate would work. Panel was a maximum of 7 people.
Purpose: Validate values match. Give insights into broader organizational dynamics.

4th round: Case study including peers + directs reports and a small selection of members of  the panel. Maximum of 12 people.
Purpose: Place for the person to demonstrate their expertise and shine, and experience a typical environment.

5th round: CEO and Chairwoman
Purpose: Validate values match, leadership and skills where appropriate.

We conducted well over 50 screenings and entered 8 very well qualified candidates into our process. The process took approximately four months to complete, approximately the same amount of time required for an executive level hire.

Laura's quote Participation in Hiring

What have we learned so far?

The hiring process for the VP of MarComm is now complete. Alex Salkever, joined Mozilla as our Vice President of Marketing Communications on May 18, 2016.

We have a hypothesis that increasing the level of diversity and participation will lead to stronger hires at Mozilla. We are continuing the pilot to explore this further.

(1) In our opinion interviews are both for the organization and the candidate

(2) Participatory hiring process in senior levels is our starting point

(3) Defining what success looks like helps identify who should participate in the hiring process

(4) Add more people early on

Gotchas:

Alex quote

Often a standard type of interview process is designed for the company, rather than the individual being interviewed. The standard process is intended to maximize assessment in a core area of expertise, whereby candidates are evaluated by their manager, peers and direct reports in their domain only. This creates an unhealthy power balance and exposes a set of addressable biases in the process such as ones based on cultural fit, and skills gap perspectives from other areas of the company.

What’s next?
We will continue to explore, record results and share further findings. We have now begun another participatory hiring experiment at the ‘director’ level role.   It’s an interesting question what piece of evidence would conclusively prove cross-functional and cross-level participation in hiring leadership brings benefits to an organization.  We’ll continue to experiment.

September 02, 2016 07:08 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

July 20, 2012

Axel Hecht

Why l10n tools should be editors instead of serializers

If your tool serializes internal state instead of editing files, it’ll do surprising things if it encounters surprising content. Like, turn

errNotSemicolonTerminated=Named character reference was not terminated by a semicolon. (Or “&” should have been escaped as “&amp;”.)

into

errNotSemicolonTerminated=Named character reference was not terminated by a semicolon. (Or “” should have been escaped as “amp;”.)

And that’s for a string the localizer never touched.

(likely narro issue 316)

July 20, 2012 04:18 PM

June 09, 2012

Axel Hecht

Rapid releases and the l10n dashboard are friends now

Wait a second, we’re on the rapid release schedule for almost a year now, and 9 releases. How can the l10n dashboard be friends with the trees only now?

Well, I’ve hacked and lied and tweaked and spoofed the data for a year. No more.

The obvious changes are:

On the team page, you’ll now see something like

You’ll notice the difference between the Current sign-off with the green check-mark, and the fx14 one with the looking glass. In the past, we’ve shown the green check-mark for both, now we’re actually showing the version that we’re using instead of the current one, and the looking glass is there to indicate that the localizer should actually look into this. There’s been a good deal of confusion about this, and I sure hope that this will resolve it a good deal.

There’s a ton of follow-up work, for one on elmo. This bug has been blocking a lot of other patches and work, both for the localizer-facing parts as well as the release infrastructure-facing parts.

More so, the state of localizations changes from “n missing strings, probably in this bucket” to “didn’t update since fx12”. That’s changing how we guide our work as l10n drivers a good deal. The impact between what we do and what localizers do becomes less anecdotal, and more science.

And there’s quite a few things we need to do, in particular for desktop.

June 09, 2012 07:07 PM