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!
Are you a locale leader and want us to include new members in our upcoming reports? Contact us!
What’s new or coming up in Firefox desktop
There are a number of new features launched recently or upcoming in Nightly to look out for.
Smart Tab Grouping
With the recent release of Tab Groups in Firefox 137, we’ll see some additional development on enhancements in the future. Currently only available in English on Nightly, Smart Tab Grouping uses a local AI model to suggest similar tabs to group together.
Link Previews
This feature will be coming to Firefox Labs in 138, Link Previews uses a local AI model to quickly see what’s behind a link, by distilling key points from the page.
Signing in PDFs
You have likely seen these strings while working on Beta, but the ability to add signatures using the built-in PDF editor will be released fully in the upcoming 138 release on April 29.
What’s new or coming up in mobile
We’re adding customization options for Firefox icons on mobile! Some of the icon names may be tricky to localize, so we’ll be sharing a reference sheet that includes each icon along with its visual and contextual usage. This will help you choose the most accurate and user-friendly translations for your locale. Keep an eye out for upcoming Pontoon notifications for more details!
What’s new or coming up in web projects
AMO and AMO Frontend
To enhance user experience, the AMO team has established a minimum translation completion threshold of 80% for locales to remain on production sites. The team will start implementing the new policy in May. Last month, locales with a completion rate of 40% or lower were removed from the production site. However, affected communities can continue making progress in Pontoon, and their status will change once they meet the threshold.
Once this new standard is fully implemented, the addon team will reassess the list of locales on a monthly basis, evaluating those that have met or fallen below the 80% threshold. Based on this review, they will determine which locales to retain and which to remove from the production site. Regardless of your locale’s current status, you can check your work in context using the links to the production, staging, and developer sites which can be found on the top left of the project dashboards.
What’s new or coming up in Pontoon
We’re working on some sizable back-end improvements to how Pontoon internally represents and deals with translatable messages, i.e. source-locale entries and their translations. Thus far we’ve refactored Pontoon’s sync code (how it reads from and writes data to project repositories) and the serialization of our supported file formats; the next step will be replacing our file format parsers.
Mostly this work should remain invisible to users, though it has already allowed us to fix quite a few long-standing bugs and improved sync performance. Eventually, this will make it much easier for us to expand the file formats and features supported by Pontoon.
Events
We are hosting our first localization office hour on Apr 30, 2025 at 3:30pm UTC, it will be live streamed on both AirMozilla and YouTube (recordings can be found at the same links). This session will focus on common errors localizers may encounter and how to overcome them. Feel free to ask questions beforehand via the Google form or reach out directly to delphine at mozilla dot com.
Want to showcase an event coming up that your community is participating in? Contact us and we’ll include it.
Friends of the Lion
Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out!
Many have commented on the Summit, some wildly enthusiastic and others more critical. On the enthusiastic side, I heard excitement about the scope of local entrepreneurs and practitioners, the explicit calls for the Africa region to take care of itself and not wait for others to “assist” to a sense of the Summit as a foundation for important future action. On the critical side I heard concerns that the amount of Western funding influencing direction, and concerns that building infrastructure like data centers gets attention relative to building other parts of the AI “stack.” I’m going to leave a evaluation of the full Summit to those with far better context and understanding of the region. For my part, I’ll focus on on the side events.
I was very heartened to see the diversity of side events that occurred during and around the Summit. I’ve found these side events can make or break an event, quite separate from the official content. The scope and diversity of side events gives a picture of how many groups feel the event touches on important topics and brings together interesting people. I attended a couple of side events myself, and learned of multiple other side events as I talked to people during the Summit. One such event was all day, bringing together policy professionals and ministerial staff. Another brought together AI practitioners from around the Continent who rarely if ever get together for in person community building. This struck me as very powerful, perhaps because I have such vivid memories of the first time the Firefox community got together. This was after we shipped Firefox 1.0, so after we had worked remotely for years to build a browser. That era was before video calls, and so we often knew each other through written materials only. Getting together physically made a dramatic mental difference and made us much more productive for a good long while. The organizer of this gathering at the Summit was practically buzzing with excitement at the chance to finally bring this community together.
I did participate in an evening panel for a research colloquium where the working energy was so loud it almost overpowered the microphones of the panelists. I also participated in a quiet breakfast side event that brought together practitioners and policy wonks for a reasonably frank discussion on what’s working and what challenges need attention. On the official side, I was part of a panel on Innovating for a Healthier Future. My main comments were focused on the themes of “open must win” and the “ethos of open.” (These are in minutes 33 to 38.)
I see the inclusion of side events as a big success. In particular, having AI practitioners, entrepreneurs, professors mixing with each other as well as policy makers and government officials. Building new things is what drives change. Policy can help or harm this effort dramatically.
A couple of months ago I started posting about how I want to build a better world through technology and how I’ll be doing that outside of Mozilla going forward. The original post has many references to “open” and “open source.” It’s easy to think that we all understand open source and we just need to apply it to new settings. I feel differently: we need to shape our collective understanding of the ethos of open source.
Open source has become mainstream as a part of the software development process. We can rightly say that the open source movement “won.” However, this isn’t enough for the future.
The open source movement was about more than convenience and avoiding payment. For many of us, open source was both a tool and an end in itself. Open source software allows people to participate in creating the software that has such great impact on our lives. The “right to fork” allows participants to try to correct wrongs in the system; it provides a mechanism for alternatives to emerge. This isn’t a perfect system of course, and we’ve seen how businesses can wrap open source and the right to fork with other systems that diminish the impact of this right. So the past is not “The Perfect Era” that we should aim to replicate. The history of open source gives us valuable learning into what works and what doesn’t so we can iterate towards what we need in this era.
The practical utility of open source software has become mainstream. The time is ripe to reinforce the deeper ethos of participation, opportunity, security and choice that drove the open source movement.
I’m looking for a good conversation about these topics. If you know of a venue where such conversations are happening in a thoughtful, respectful way please do let me know.
I’m on my way to the Global AI Summit on Africa in Kigali on April 3 and 4, thanks to an invitation from the Ministry organizing the event. I’ll be speaking, but mostly listening and learning and hopefully connecting with people who are drawn to approaches that are open and creative. If you know someone at this event I should meet, please do let me know.
I’m scheduled to be the main guest at the Fireside Chat on April 1. I’ll also be participating in the panel “Innovating for a Healthier Future.” This panel topic combines open source and health with new AI developments. I’ve been working with OpenMRS (as a board member) on open source electronic medical records for better outcomes for some years. I’m eager to dive into the impacts of AI on this work with the broad set of experts at the Summit.
After the Summit, I’ll spend a few days in Nairobi. I’ll say more about the Summit shortly.
I’ve been thinking a lot about how we need to shape our collective understanding of the ethos of open source, and how to use business as a tool to promote mission-based work.
Here are a few areas where ideas are percolating and I expect to write more soon:
What does the evolution of open source from “radical” niche developers into the consumer mainstream teach us?
It’s clear that “open must win” in the AI realm so that public benefit is magnified. This is a huge topic, from definitions to community building to integrating open projects into robust products.
How does one use business as a tool to promote a mission, or to support a mission based organization?
This is a space I’ve been living in for 25 years and is more important than ever. I’ve lived through the changes different styles of leadership and different priorities can make. I’ve experienced how the logic of business is very strong, while unconventional thinking is — well — unconventional, and harder to institutionalize. I’ve experienced, and in some cases led, some big wins here and some big misses as well. I have a lot of ideas about how to do this in the current environment. I’m not alone in this, there’s a growing community of people thinking about these areas with whom I’m eager to connect.
Time of Disruption
So much is changing now. It’s a time of disruption at the individual, national and global levels. This means new ways of creating and organizing activities and developing new institutions is necessary. We need the positive forces of building and doing to be a part of the coming new order.
These topics are just a starting point. I want to get involved with people doing related activities, building, supporting, funding new technology and new systems. If you are deep in one of these areas, please do ping me.
I am driven to build a better world through how we build technology that promotes opportunity, agency, and public benefit. I have pursued this mission through Mozilla for more than 25 years – first as a Netscape employee, then as a volunteer leader of Mozilla, then as the co-founder and leader of Mozilla Foundation and Mozilla Corporation. I am still driven by this mission, which is as important as ever. I will of course always be the co-founder of Mozilla but going forward I will pursue this mission outside of Mozilla.
I’ll share more details on my next steps soon. Today I want to focus on how I’ll be approaching this mission outside of Mozilla.
Mozilla’s upcoming era will have a focus on managing its portfolio of organizations, and the work described in Mozilla’s recent blog post. My personal approach going forward will be quite different. I’m aiming for new incarnations of the heart and spirit that built the open source movement and created Mozilla.
As Mozilla has grown I’ve experienced the opportunities and challenges in operating a $1 billion+ organization that is also a global technology platform and the flag-bearer for so many aspirations for a better internet. It’s a wildly valuable experience, and quite rare in the “open must win” world. I increasingly feel the pull to connect these experiences to new grassroots entrepreneurs, builders and movements. If I had had access to this experience when we were starting Mozilla it would have been a huge asset.
I have another creative burst or two in me waiting for the right opportunity. I know that the ethos of “open” and the principles of the Mozilla Manifesto are each increasingly important in the world today. There are only a handful of people who have lived through the explosion of “open” into the mainstream, who have developed that into a successful consumer product based on values, and then led an organization and a community through global scale and impact. I am one of this very small group and I feel compelled to use this experience to support others working in related fields. I want to find other people who are building things because those things need to exist in the world first, and then figure out how to generate revenue and build sustainability. I’m looking to immerse myself in opportunities that generate true creativity and breathe life into something new.
I’m learning exciting things these days. It has become even clearer to me that both “open must win” and the passion that has driven my leadership of Mozilla remain a clarion call for me. I will continue to explore my contribution to these areas in the next phase of my work through a broad range of contexts. In addition, the ability to represent this perspective in the public discourse is an honor and a responsibility to which I remain committed.
By “building a better world through how we build technology” I mean:
Offering more opportunities to more people to participate in creating our world, independent of educational pedigree or job title.
Internalizing “open” and open source as both a means and an end in itself.
Using open source to offer a “trust but verify” approach to how our technology operates and how it impacts individual sovereignty and our society.
Using private initiative to build public good – building business as a tool for public benefit.
Deepening transparency and individual agency.
Creating technology through combined efforts and shared assets.
I think of this approach as advocacy through building technology, using an “architecture of participation.” Many of us think of it as the ethos of open source. The possibility of this approach is hard to internalize until one experiences this directly, and is wildly powerful once one has. It’s the power that made Mozilla successful. Personally, it’s the power that kept me going whenever the work was really hard. And it’s the power that drives me to want to continue building and working on the “open must win” ethos.
The inspiration and impact of Mozilla are beyond anything I could have imagined. Words cannot express my gratitude to every one of you who chooses Mozilla, supports Mozilla, volunteers, chooses open, works for the public benefit, and resonates to the ideals we captured in the Mozilla Manifesto. I’m humbled by each of you who has chosen me as your leader, allows me to represent you in the world, and gives me the support to bring the best of our shared work into the world. This is a level of trust and commitment that I am proud and honored to have earned. It’s my deep hope to build on that in ways that reflect the core principles that have brought us together.
You can reach me on Mastodon or BlueSky or Linkedin or here at hello@mitchellbaker.net where I’ll provide updates. Mozilla email should forward to me for the next few months. Those of you who know me well enough to have my personal contact info, or to know someone who does, please do feel free to contact me. I may be slow to respond, but I’m driven by community and inspired by Mozillians, so don’t be shy!
I’ll share more details on my next steps soon. Today I want to focus on how I’ll be approaching this mission outside of Mozilla.
Mozilla’s upcoming era will have a focus on managing its portfolio of organizations, and the work described in Mozilla’s recent blog post. My personal approach going forward will be quite different. I’m aiming for new incarnations of the heart and spirit that built the open source movement and created Mozilla.
As Mozilla has grown I’ve experienced the opportunities and challenges in operating a $1 billion+ organization that is also a global technology platform and the flag-bearer for so many aspirations for a better internet. It’s a wildly valuable experience, and quite rare in the “open must win” world. I increasingly feel the pull to connect these experiences to new grassroots entrepreneurs, builders and movements. If I had had access to this experience when we were starting Mozilla it would have been a huge asset.
I have another creative burst or two in me waiting for the right opportunity. I know that the ethos of “open” and the principles of the Mozilla Manifesto are each increasingly important in the world today. There are only a handful of people who have lived through the explosion of “open” into the mainstream, who have developed that into a successful consumer product based on values, and then led an organization and a community through global scale and impact. I am one of this very small group and I feel compelled to use this experience to support others working in related fields. I want to find other people who are building things because those things need to exist in the world first, and then figure out how to generate revenue and build sustainability. I’m looking to immerse myself in opportunities that generate true creativity and breathe life into something new.
I’m learning exciting things these days. It has become even clearer to me that both “open must win” and the passion that has driven my leadership of Mozilla remain a clarion call for me. I will continue to explore my contribution to these areas in the next phase of my work through a broad range of contexts. In addition, the ability to represent this perspective in the public discourse is an honor and a responsibility to which I remain committed.
By “building a better world through how we build technology” I mean:
Offering more opportunities to more people to participate in creating our world, independent of educational pedigree or job title.
Internalizing “open” and open source as both a means and an end in itself.
Using open source to offer a “trust but verify” approach to how our technology operates and how it impacts individual sovereignty and our society.
Using private initiative to build public good – building business as a tool for public benefit.
Deepening transparency and individual agency.
Creating technology through combined efforts and shared assets.
I think of this approach as advocacy through building technology, using an “architecture of participation.” Many of us think of it as the ethos of open source. The possibility of this approach is hard to internalize until one experiences this directly, and is wildly powerful once one has. It’s the power that made Mozilla successful. Personally, it’s the power that kept me going whenever the work was really hard. And it’s the power that drives me to want to continue building and working on the “open must win” ethos.
The inspiration and impact of Mozilla are beyond anything I could have imagined. Words cannot express my gratitude to every one of you who chooses Mozilla, supports Mozilla, volunteers, chooses open, works for the public benefit, and resonates to the ideals we captured in the Mozilla Manifesto. I’m humbled by each of you who has chosen me as your leader, allows me to represent you in the world, and gives me the support to bring the best of our shared work into the world. This is a level of trust and commitment that I am proud and honored to have earned. It’s my deep hope to build on that in ways that reflect the core principles that have brought us together.
You can reach me on Mastodon or BlueSky or Linkedin or here at hello@mitchellbaker.net where I’ll provide updates. Mozilla email should forward to me for the next few months. Those of you who know me well enough to have my personal contact info, or to know someone who does, please do feel free to contact me. I may be slow to respond, but I’m driven by community and inspired by Mozillians, so don’t be shy!
We thank everyone who dedicated their time to share valuable responses and suggest potential features for us to consider implementing!
Each user could give each feature 1 to 5 votes. A total of 154 Pontoon users participated in the survey, 68 of which voted on all features. The number of participants is lower than in the past years, since we only reached out to users who explicitly opted-in to email updates.
We look forward to implementing these new features and working towards a more seamless and efficient translation experience with Pontoon. Stay tuned for updates!
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!
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
Tab Groups
Tab groups are now available in Nightly 136! To create a group in Nightly, all you have to do is have two tabs open, click and drag one tab to the other, pause a sec and then drop. From there the tab group editor window will appear where you can name the group and give it a color. After saving, the group will appear on your tab bar.
Once you create a group, you can easily access your groups from the overflow menu on the right.
These work great in the sidebar and vertical tabs feature that was released in the Firefox Labs feature in Nightly 131!
New profile selector
The new profile selector which we have been localizing over the previous months is now starting to roll out gradually to users in Nightly 136. SUMO has an excellent article about all the new changes which you can find here.
What’s new or coming up in web projects
AMO and AMO Frontend
The team is planning to migrate/copy the Spanish (es) locale into four: es-AR, es-CL, es-ES, and es-MX. Per the community managers’ input, all locales will retain the suggestions that have not been approved at the time of migration. Be on the lookout for the changes in the upcoming week(s).
Mozilla Accounts
The Mozilla accounts team recently landed strings used in three emails planned to be sent over the course of 90 days, with the first happening in the coming weeks. These will be sent to inactive users who have not logged in or interacted with the Mozilla accounts service in 2 years, letting them know their account and data may be deleted.
What’s new or coming up in SUMO
The CX team is still working on 2025 planning. In the meantime, read a recap from our technical writer, Lucas Siebert about how 2024 went in this blog post. We will also have a community call coming up on Feb 5th at 5 PM UTC. Check out the agenda for more detail and we’d love to see you there!
Last but not least, we will be at FOSDEM 2025. Mozilla’s booth will be at the K building, level 1. Would love to see you if you’re around!
What’s new or coming up in Pontoon
New Email Features
We’re excited to announce two new email features that will keep you better informed and connected with your localization work on Pontoon:
Email Notifications: Opt in to receive notifications via email, ensuring you stay up to date with important events even when you’re away from the platform. You can choose between daily or weekly digests and subscribe to specific notification types only.
Monthly Activity Summary: If enabled, you’ll receive an email summary at the start of each month, highlighting your personal activity and key activities within your teams for the previous month.
Visit your settings to explore and activate these features today!
New Translation Memory tools are here!
If you are a locale manager or translator, here’s what you can do from the new TM tab on your team page:
Search, edit, and delete Translation Memory entries with ease.
Upload .TMX files to instantly share your Translation Memories with your team.
These tools are here to save you time and boost the quality of suggestions from Machinery. Dive in and explore the new features today!
Moving to GitHub Discussions
Feedback, support and conversations on new Pontoon developments have moved from Discourse to GitHub Discussions. See you there!
Newly published localizer facing documentation
How to test mozilla.org was updated to reflect some of the changes to the site in the last year or so.
Events
Come check out our end of year presentation on Pontoon! A Youtube link and AirMozilla link are available.
Want to showcase an event coming up that your community is participating in? Contact us and we’ll include it.
Friends of the Lion
Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out!
2024 was a year with plenty of achievements for the Mozilla localization community (here’s the 2023 report in case you missed it, or want to check how we fared against our original plans). Let’s start with the numbers first:
30 projects (-2 compared to last year) and 369 locales (+111) set up in Pontoon.
4,991 new user registrations
1,202 active users, submitting at least one translation (on average 222 users per month)
466,187 submitted translations
385,722 approved translations
20,931 new strings to translate
While the overall number of projects decreased, this is mostly due to removal of obsolete projects (we actually added a new one in November). The astounding increase in the number of locales is driven once again by Common Voice, which has 318 locales enabled in Pontoon.
Thank you to all the volunteers who contributed their time, passion, and expertise to Mozilla’s localization over the last 12 months.
Pontoon Development
At the start of the year, we focused on improving Pontoon’s performance — a less glamorous but essential part of maintaining an effective platform: if the platform doesn’t perform well, users can quickly lose motivation and stop contributing. To assess the current state, we used the Apdex score, a standard measure of user satisfaction for web application performance. Between January and March, we successfully raised the average score for our lowest performing transactions from 0.77 to 0.87, making significant progress toward achieving what is considered a “good” performance level. Later in the year, we also moved to a larger database plan to further improve performance.
In May, we launched our first LLM integration. Users now have additional options if they’re not satisfied with the suggestion provided by Google Translate. They can choose from three actions: Rephrase, to generate an alternative version; Make formal, to adjust the tone to a more formal register; and Make informal, to create a more casual version. These options are especially valuable for languages like German or Spanish, where tone can significantly impact translation quality and consistency.
Between May and December 2024, this feature has been used 2,571 times across 69 locales, with approximately 35% of the generated text being copied into the editor. This adoption rate suggests that the feature is delivering good-quality results and meeting user needs effectively, and that we should look into expanding its use.
In October, we introduced advanced search options, giving users more flexibility and precision in finding the content they need. By default, Pontoon now searches through source text, approved translations, and pending suggestions. However, users still retain the option to expand their search to include identifiers, rejected translations, or further refine results by matching case or whole words.
For more details on how to use this feature, check out our documentation. We’re currently analyzing the usage data to understand if we should change the default options, and exploring how to make the feature more discoverable.
December was an especially busy month for releasing new features. We kicked things off with the long-awaited ability to edit translation memory (TM) entries, addressing one of the most frequently requested enhancements from our users. Shortly after, we introduced another powerful feature: the ability to upload custom translation memories in TMX format, giving locales even more control over their localization workflows.
We also launched our first glimpse of gamification! Users can now earn three different types of badges for translating, reviewing, and promoting other contributors. The goal isn’t just to recognize and celebrate the invaluable efforts of volunteers but also to encourage positive behaviors. These include reviewing others’ work and promoting promising contributors, helping communities grow and encouraging effective participation across the platform.
As part of this work we also introduced user banners to help clarify roles within a locale or project.
Finally, we wrapped up the year by enhancing Pontoon’s ability to keep users informed. Users can now opt to receive notifications via email, choosing between daily or weekly updates. Additionally, we introduced a Monthly Activity Summary — a digest that highlights both their personal contributions and their team’s activity. If you’re a locale manager, we highly recommend enabling this feature to stay on top of your community’s progress and engagement.
If you check your settings, you’ll find a new option for News and Updates. We highly encourage users to enable this checkbox to stay informed about online events, new features, surveys, and more. The content will be strictly focused on Mozilla Localization and Pontoon, and you can opt out or change your preferences at any time.
Lastly, a lot of work happened behind the scenes to improve Pontoon’s functionality and stability. We introduced the Messaging Center, a new feature that enables program managers to communicate with users more effectively through targeted notifications or emails.
In addition, we’ve been rewriting the code responsible for syncing Pontoon with repositories. This foundational work lays the groundwork for a broader set of initiatives planned for 2025. We also implemented measures to mitigate DDoS attacks, ensuring the platform remains stable, secure, and reliable for all users.
Community
This year, we collaborated with members of the community and other community-focused teams at Mozilla to improve our existing documentation and create comprehensive community guidelines aimed at building vibrant and sustainable communities. These guidelines address key topics, such as the expectations for managers and translators, and provide clear processes for assigning permissions to new contributors when existing leaders are not available.
Unfortunately, the situation around in-person community events hasn’t changed. We know how important these gatherings are for you — and for us — but in the meantime, we continued to focus on organizing online events. You can find all the recordings for the 2024 events here. We’ve also recorded an Introduction to Pontoon, designed to help onboard new contributors and familiarize them with the platform.
What’s coming in 2025
While we made significant strides in improving Pontoon’s performance this year, we believe that we’ve reached the limits of our current setup. As we move into the new year, our focus will shift to exploring alternative deployment solutions. Our goal is to make Pontoon faster, more reliable, and better equipped to meet the needs of our users.
We aim to make mobile projects (Android and iOS) first-class citizens in our localization ecosystem. The first step is introducing support for plural forms, which will significantly enhance the localizability of these projects. This improvement will enable more natural-sounding content in English and other languages, ensuring a better experience for both contributors and end users.
Talking about Pontoon, we’re committed to improving translation memory utilization, particularly for handling multi-value strings commonly found in Fluent. Currently, Pontoon only suggests translations for a single value within these strings. Moving forward, we aim to provide suggestions or translation memory matches for entire strings, ensuring a more comprehensive and efficient translation experience.
We plan to work on a Mozilla Language Portal — a unified hub that highlights Mozilla’s unique approach to localization while serving as a comprehensive resource for translators. This webpage will feature searchable translation memories, a rich repository of documentation, best practices, blogs, and more, fostering knowledge-sharing and collaboration across the global translation community.
Finally, we will continue exploring innovative ways to engage our community and strengthen its connections. As part of this work, we will keep advocating for increased investment in community building at the organization level, emphasizing its critical role in driving our mission forward.
If you have any thoughts or ideas about this plan, let us know on Mastodon or Matrix!
Thank you!
As we step into 2025, we’re constantly reminded of the transformative power of localization. Together, we’ll continue to break down barriers, and create a digital world that speaks everyone’s language. Thank you for being part of this journey.
We’re shaping the future of Pontoon, and your input is crucial! As we plan our 2025 roadmap, we’re committed to implementing at least three of the features most important to you—our users. Now’s your chance to tell us what matters most.
At the heart of Mozilla’s localization efforts lies Pontoon, our in-house translation management system. Powered by our vibrant volunteer community, Pontoon thrives on their commitments to submit and review translations across all our products.
As part of our ongoing attempts to further recognize the contributions of Pontoon’s volunteers, the localization team has been exploring new ways to celebrate their achievements. We know that the success of localization at Mozilla hinges on the dedication of our community, and it’s important to not only acknowledge this effort but to also create an environment that encourages even greater participation.
That’s why we’re excited to introduce achievement badges in Pontoon! Whether you’re new to Pontoon or a seasoned contributor, achievement badges not only recognize your contribution but also encourage participation and promote good habits amongst our community.
With achievement badges, we aim to make contributing to Pontoon more rewarding and fun while reinforcing Mozilla’s mission of building an open and accessible web for everyone, everywhere.
What are achievement badges?
Achievement badges are a symbol recognizing your hard work in keeping the internet accessible and open, no matter where users are located. These badges are displayed on your Pontoon profile page.
In collaboration with Mozillian designer Céline Villaneau, we’ve created three distinct badges to promote different behaviors within Pontoon:
Translation Champion, awarded for submitting translations.
Review Master, awarded for reviewing translations.
Community Builder, awarded for promoting users to higher roles.
Receiving a badge
When the threshold required to receive a badge is crossed, you’ll receive a notification along with a pop-up tooltip (complete with confetti!). The tooltip will display details about the badge you’ve just earned.
To give you more of a challenge, each badge comes with multiple levels, encouraging continued contributions to Pontoon. You’ll receive similar notifications and celebratory tooltips whenever you unlock a new badge level.
Start collecting!
Badges are more than just icons — they’re a celebration of your dedication to keeping the web accessible to all. Ready to make your mark? All users will begin with a blank slate, so start contributing and begin your badge collection today!
We’re excited to announce that Thunderbird Desktop will soon offer monthly releases through the Release channel as a supported alternative to the ESR channel. This means a new major version of Thunderbird will be available every month, providing the following benefits for our users:
Frequent Feature Updates: New features will be available each month, rather than waiting for the annual Extended Support Release (ESR).
Smoother Transitions: Moving from one monthly release to the next will be less disruptive than updating between ESR versions.
Consistent Bug Fixes: Users will receive all available bug fixes, rather than relying on patch uplifts, as is the case with ESR.
Expanding Thunderbird’s Channels
Currently, Thunderbird offers three release channels: Daily, Beta, and ESR. With the addition of the Release channel, we’ll soon provide stable, monthly releases. Over time, this Release channel will become the default channel.
Current Status
The Thunderbird Release channel is currently available for testing purposes only. We have been publishing monthly releases for a few months now, and we will continue publishing new releases as we progress toward officially supporting the Thunderbird Release channel.
Translation Support
We are immensely grateful to our translators for their ongoing contributions in localizing Thunderbird. If you have any questions regarding translations for Thunderbird, please feel free to reach out to corey@thunderbird.net.
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.
New community/locales added
We’re grateful for the Abzhaz community’s initiative in reaching out to localize our products. Thank you for your valuable involvement!
New content and projects
What’s new or coming up in Firefox desktop
Search Mode Switcher
A new feature in development has become available (behind a flag) with the release of the latest Nightly version 133: the Search Mode Switcher. You may have already seen strings for this land in Pontoon, but this feature enables you to enter a search term into the address bar and search through multiple engines. After entering the search term and selecting a provider, the search term will persist (instead of showing the site’s URL) and then you can select a different provider by clicking an icon on the left of the bar.
Firefox Search Mode Switcher
You can test this now in version 133 of Nightly by entering about:config in the address bar and pressing enter, proceed past the warning, and search for the following flag: browser.urlbar.scotchBonnet.enableOverride. Toggling the flag to true will enable the feature.
New profile selector
Starting in Version 134 of Nightly a new feature to easily select, create, and change profiles within Firefox will begin rolling out to a small number of users worldwide. Strings are planned to be made available for localization soon.
Sidebar and Vertical Tabs
Finally, as previously mentioned in the previous L10n Report, features for a new sidebar with expanded functionality along with the ability to change your tab layout from horizontal to vertical are available to test in Nightly through the Firefox Labs feature in your settings. Just go to your Nightly settings, select the Firefox Lab section from the left, and enable the feature by clicking the checkbox. Since these are experimental there may continue to be occasional string changes or additions. While you check out these features in your languages, if you have thoughts on the features themselves, we welcome you to share feedback through Mozilla Connect.
What’s new or coming up in web projects
AMO and AMO Frontend
To improve user experience, the AMO team plans to implement changes that will enable only locales meeting a specific completion threshold. Locales with very low completion percentages will be disabled in production but will remain available on Pontoon for teams to continue working on them. The exact details and timeline will be communicated once the plan is finalized.
Mozilla Accounts
Currently Mozilla Accounts is going through a redesign of some of its log-in pages’ user experiences. So we will continue to see small updates here and there for the rest of the year. There is also a planned update to the Mozilla Accounts payment sub platform. We expect to see a new file added to the project before the end of the year – but a large number of the strings will be the same as now. We will be migrating those translations so they don’t need to be translated again, but there will be a number of new strings as well.
Mozilla.org
The Mozilla.org site is undergoing a series of redesigns, starting with updates to the footer and navigation bars. These changes will continue through the rest of the year and beyond. The next update will focus on the About page. Additionally, the team is systematically removing obsolete strings and replacing them with updated or new strings, ensuring you have enough time to catch up while minimizing effort on outdated content.
There are a few new Welcome pages made available to a select few locales. Each of these pages have a different deadline. Make sure to complete them before they are due.
What’s new or coming up in SUMO
The SUMO platform just got a navigation redesign in July to improve navigation for users & contributors. The team also introduced new topics that are standardized across products, which lay the foundation for better data analysis and reporting. Most of the old topics, and their associated articles and questions, have been mapped to the new taxonomy, but a few remain that will be manually mapped to their new topics.
On the community side, we also introduced improvements & fixes on the messaging feature, changing the KB display time in format appropriate to locale, fixed the bug so we can properly display pageviews number in the KB dashboard, and add a spam tag in the list of question if it’s marked as spam to make moderation work easier for the forum moderators.
There will be a community call coming up on Oct 30 at 5pm UTC where we will be talking about Firefox 20th anniversary celebration and Firefox 132 release. Check out the agenda for more detail.
What’s new or coming up in Pontoon
Enhancements to Pontoon Search
We’re excited to announce that Pontoon now allows for more sophisticated searches for strings, thanks to the addition of the new search panel!
When searching for a string, clicking on the magnifying glass icon will open a dropdown, allowing users to select any combination of search options to help refine their search. Please note that the default search behavior has changed, as string identifiers must now be explicitly enabled in search options.
Pontoon Enhanced Search Options
User status banners
As part of the effort to introduce badges/achievements into Pontoon, we’ve added status banners under user avatars in the translation workspace. Status banners reflect the permissions of the user within the respective locale and project, eliminating the need to visit their profile page to view their role.
Namely, team managers will get the ‘MNGR’ tag, translators get the ‘TRNSL’ tag, project managers get the ‘PM’ tag, and those with site-wide admin permissions receive the ‘ADMIN’ tag. Users who have joined within the last three months will get the ‘NEW USER’ tag for their banner. Status banners also appear in comments made under translations.
New Pontoon logo
We hope you love the new Pontoon logo as much as we do! Thanks to all of you who expressed your preference by participating in the survey.
Pontoon New Logo
Friends of the Lion
Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out!
When I began my 16-month journey as a Software Engineer intern at Mozilla, I had no idea how enriching the experience would be. I had just finished my third-year as a computer science student at the University of Toronto, passionate about Artificial Intelligence (AI), Machine Learning (ML), and software engineering, with a thirst for hands-on experience. Mozilla, with its commitment to the open web and global community, was the perfect place for me to grow, learn, and contribute meaningfully.
Starting off strong on day one at Mozilla—calling the shots from the big screen :)!
Integrating into a Global Team
Joining Mozilla felt like being welcomed into a global family. Mozilla’s worldwide presence meant that asynchronous communication was not just a convenience but a necessity. My team was scattered across various time zones around the world—from Berlin to Helsinki, Slovenia to Seattle, and everywhere in between. Meanwhile, I was located in Toronto, where morning standups became my lifeline. The early hours of the day were crucial; I had to ensure all my questions were answered before my teammates signed off for the day. Collaborating across continents with a diverse team honed my adaptability and proficiency in asynchronous communication, ensuring smooth project progress despite time zone differences. This taught me the art of clear, concise communication and the importance of being proactive in a globally distributed team.
Our weekly team meeting, connecting from all corners of the globe!
Working on localization with such a diverse team gave me a unique perspective. I learned that while we all used the same technology, the challenges and solutions were as diverse as the locales we supported. This experience underscored the importance of creating technology that is not just globally accessible but also locally relevant.
Who knew software engineering could be so… circus-y? Meeting the team in style at Mozilla’s All Hands event in Montréal!
Building Success Through Teamwork
During my internship, I was treated as a full-fledged engineer, entrusted with significant responsibilities that allowed me to lead projects. This experience honed my strategic thinking and built my confidence, but it also taught me the importance of collaboration. Working closely with a team of three engineers, I quickly learned that effective communication was essential to our success. I actively participated in code reviews, feature assessments, and bug resolutions, always keeping my team informed through regular updates in standups and Slack. This open communication not only fostered strong relationships but also made me an effective team player, ensuring that our collective efforts were aligned and that we could achieve our goals together.
Driving Innovation
One of the things I quickly realized at Mozilla was that innovation isn’t just about coming up with new ideas—it’s about identifying areas for improvement and enhancing them. My interest in AI led me to spot an opportunity to elevate the translation process in Pontoon, Mozilla’s localization platform. After thorough research and discussions with my mentor and team, I proposed integrating large language models to boost the platform’s capabilities. This proactive approach not only enhanced the platform but also showcased my ability to think critically and solve problems effectively.
Diving into the Tech Stack
Mozilla gave me the opportunity to dive deep into a tech stack that was both challenging and exciting. I worked extensively with Python using the Django framework, React, TypeScript, and JavaScript, along with HTML and CSS. But it wasn’t just about the tools—it was about applying them in ways that would have a lasting impact.
One of my most significant projects was leading the integration of GPT-4 into Pontoon. This wasn’t just about adding another tool to the platform; it was about enhancing the translation process in a way that captured the subtle nuances of language, something that traditional machine translation tools often missed. The result? A feature that allowed localizers to rephrase text, or make text more formal or informal as needed, ultimately ensuring that Mozilla’s products resonated with users worldwide.
This project was a full-stack adventure. From prompt engineering on the backend to crafting a seamless frontend interface, I was involved in every stage of the development process. The impact was immediate and widespread—by August 2024, the feature had been used over 2,000 times across 52 distinct locales. Seeing something I worked on make such a tangible difference was incredibly rewarding. You can read more about this feature in my blog post here.
Another project that stands out is the implementation of a light theme in Pontoon, aimed at promoting accessibility and enhancing user experience. Recognizing that a single dark theme could be straining for some users, I spearheaded the development of a light theme and system theme option that adhered to accessibility standards and catered to diverse user preferences. Within the first six months of its launch, the feature was adopted by over 14% of users who logged in within the last 12 months, significantly improving usability and demonstrating Mozilla’s commitment to inclusive design.
Building a Stronger Community
Mozilla’s commitment to community is one of the things that drew me to the organization, and I was thrilled to contribute to it in meaningful ways. One of my proudest achievements was initiating the introduction of gamification elements in Pontoon. The goal was to enhance community engagement by recognizing and rewarding contributions through badges. By analyzing user data and drawing inspiration from platforms like Duolingo and GitHub, I helped design a system that not only motivated contributors but also enhanced the trustworthiness of translations.
But my impact extended beyond that. I had the opportunity to interact with our global audience and participate in various virtual events focused on engaging with our localization community. For instance, I took part in the “Three Women in Localization” interview, where I shared my experiences as a female engineer in the tech industry. I also participated in a fireside chat with the localization tech team to discuss our work and the future of localization at Mozilla. More recently, I organized a live virtual interview featuring the Firefox Translations team, which turned out to be our most engaging online event to date. It was an incredible opportunity to connect with Mozilla’s global community, discuss important topics like privacy and AI, and facilitate real-time interaction. These experiences not only allowed me to share my insights but also deepened my understanding of the broader community that powers Mozilla’s mission.
Joining forces with the inspiring women of Mozilla’s localization team during the “Three Women in Localization” interview, where we shared our experiences and insights as females in the tech industry.
From Mentee to Mentor
During the last four months of my internship, I had the opportunity to mentor and onboard our new intern, Harmit Goswami, who would be taking over my role once I returned to my last semester of university. My team entrusted me with this responsibility, and I guided him through the onboarding process—helping him get everything set up, introducing him to the codebase, and supporting him as he tackled his first bugs.
Mentoring our new intern, Harmit, as he joins our weekly tech team call for the first time from the Toronto office—welcoming him to the Mozilla family, one Zoom call at a time!
This experience taught me the importance of clear communication, setting expectations, and creating a learning path for his growth and success. I was fortunate to have an amazing mentor, Matjaž Horvat, throughout my internship, and it was incredibly rewarding to take what I had learned from him and pass it on. In the process, I also gained a deeper understanding of my own skills and how to teach and guide others effectively.
Learning and Growing Every Day
The fast-paced, collaborative environment at Mozilla pushed me to learn new technologies and skills on a tight schedule. Whether it was diving into Django for backend development or mastering the intricacies of version control with Git and GitHub, I was constantly learning and growing. More importantly, I learned the value of adaptability and how to thrive in an open-source work culture that was vastly different from my previous experiences in the financial sector.
Reflecting on the Journey
As I wrap up my internship, I can’t help but reflect on how much I’ve grown—both as an engineer and as a person.
As a person, I was able to step out of my comfort zone and host virtual events that were open to both the company and the public, enhancing my confidence and public speaking skills. Engaging with a diverse audience and facilitating meaningful discussions taught me the importance of effective communication and community engagement.
As an engineer, I had the opportunity to lead my own projects from the initial idea to deployment, which allowed me to fully immerse myself in the software development lifecycle and project management. This experience sharpened my technical acumen and taught me how to provide constructive feedback during senior code reviews, ensuring code quality and adherence to best practices. Beyond technical development, I expanded my expertise by adopting a user-centric approach—writing proposal documents, conducting research, analyzing user data, and drafting detailed specification documents. This comprehensive approach required me to blend technical skills with strategic thinking and user-focused design, ultimately refining my problem-solving, research, and communication abilities. These experiences made me a more versatile and well-rounded engineer.
This journey has been about more than just writing code. It’s been about building something that matters, connecting with a global community, and growing into the kind of engineer who not only solves problems but also embraces challenges with creativity and resilience. As I look ahead to the future, I’m excited to continue this journey, armed with the knowledge, skills, and passion that Mozilla has helped me cultivate.
Acknowledgments
I want to extend my deepest gratitude to my manager, Francesco Lodolo, and my mentor, Matjaž Horvat, for their unwavering support and guidance throughout my internship. To my incredible team and the entire Mozilla community, thank you for fostering an environment of learning, collaboration, and innovation. This experience has been invaluable, and I will carry these lessons and memories with me throughout my career.
*Thank you for reading about my journey! If you have any questions or would like to discuss my experiences further, feel free to reach out via Linkedin.
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.
New content and projects
What’s new or coming up in Firefox desktop
Last month you may have seen “Firefox Labs” while translating in the Firefox project. In the coming months a number of new experimental features are being made available in Firefox through Firefox Labs, allowing users to test out and provide feedback (through Mozilla connect) on in-development features. You will be able to turn those features on and off by navigating to your about:settings page and clicking ”Firefox Labs.” You can test it out yourself in Nightly right now.
Starting from the upcoming Firefox version 131 you should start seeing strings to localize for a number of new experimental features.
AI Chatbot
You may have noticed this feature in the current version of Nightly already. With this enabled, you can add AI chatbots such as ChatGPT to the sidebar. When added, users can also select text on a page and use the context menu to choose a pre-generated prompt. This feature is being opened for localization in version 131, and in addition to the regular UI strings you would expect, the prompts for sending to the chatbot will also be available to localize.
Localizing chatbot prompts
You can localize these prompts as usual, but you may want to test potential prompts out to see the quality of the results returned and tweak if necessary. Please find some additional background information from the development team to help you when localizing these:
Starting with Firefox version 130, users can choose to add an AI chatbot to their browser. This feature will be added to the Settings > Firefox Labs page, where interested users can choose to try it out. The chatbots users can choose from: Anthropic Claude, ChatGPT, Google Gemini, Hugging Chat, Le Chat Mistral.
In addition to having the chatbot in the sidebar, when users select text on a webpage, we will suggest several actions the user can ask the chatbot to perform. Selecting an action sends the selection, the page title, and a prompt that we have written to the chatbot provider.
Prompts are the plain language ‘instructions’ for the chatbot and will be visible in the provider’s interface.
About our prompts
This table lists the actions, their purpose, and the prompt.
Action
Purpose
Prompt
Summarize
Help users understand what a selection covers at a glance
Please summarize the selection using precise and concise language. Use headers and bulleted lists in the summary, to make it scannable. Maintain the meaning and factual accuracy.
Explain this
Help users understand unfamiliar words and topics
Please explain the key concepts in this selection, using simple words. Also, use examples.
Simplify language
Make a selection easier to read
Please rewrite the selection using short sentences and simple words. Maintain the meaning and factual accuracy.
Quiz me
Test understanding of selection in an interactive way
Please quiz me on this selection. Ask me a variety of types of questions, for example multiple choice, true or false, and short answer. Wait for my response before moving on to the next question
Writing style of prompts
In English, we have made the prompts concise and direct for a few reasons:
Some providers have character restrictions around how much can be input into their chat interface (the ‘context window’). The length of the prompt plus the length of the selection are included in this character count.
Being direct provides less room for misinterpretation of the instructions.
When localizing, please strive also for being concise and direct, but not at the expense of losing meaning. We understand this style may feel more “formal” than some of our other strings.
Sidebar customization / Vertical tabs
In addition to the AI chatbot mentioned above, more changes to the sidebar are in the works including the addition of vertical tabs. Keep your eye out for this experiment and associated strings coming in 131.
Upcoming features
In addition to the experiments planned for 131, there are more new features we can look forward to in later versions. Currently in active development are features related to profile management as well as creation of encrypted backups of your Firefox data.
What’s new or coming up in mobile
Firefox for Android has two exciting new features, and we’d love your help testing them out! Please use the Nightly version in both cases (which is the version you should be using anyways in order to test your localization work).
The first one is the Translation feature, which you can access by navigating to any website, and then going to Settings > Translate page. Play around with the feature, for example you can translate a page from English to French, and then from French to another language you may speak.
If you encounter any problems whatsoever, please file a bug here, under the Component “Translations”. Under “Type”, chose “Defect”.
Secondly, there is an entire toolbar menu redesign! This is not available by default on Nightly yet, so you will have to enable it through Secret Settings. To do so, go to Settings > About Firefox Nightly, and click 5 times on the Firefox Nightly logo. This will enable the Secret Settings, which you can access by clicking on the back arrow (which brings you back to Settings). Scroll down until you see “Secret Settings”. Then select both “Enable Navigation Toolbar” and “Enable Menu Redesign”. You’ll immediately notice the difference once you navigate via the bottom toolbar.
Please play around with this new feature as much as possible in your language – look out especially for truncations, as we expect to see quite a few.
If you encounter any problems whatsoever, please file a bug here, under the Component “Toolbar”. Under “Type”, chose “Defect”.
Firefox for iOS is expected to incorporate these changes in the future; however, that work has not started yet.
What’s new or coming up in SUMO
The next community call is coming up on August 7, 2024. We’ll talk about what’s coming in Firefox 129 as well as have a discussion with the lead editor of the IRL podcast to talk about their next season, “AI and Me.” Join us on Wednesday, August 7, 5pm UTC!
If you want to get updated on the upcoming Firefox release, check out our release wiki page for Firefox 129 to stay updated with known issues/dot releases. We’ve been doing this since Firefox 126 and it’s pretty well-received by the community.
Recently, we also teamed up with the Firefox team to organize the Firefox third-party installer campaign. As a result, we received 1,844 reports in total, identified 683 unique third-party websites and 105 unique download links. The Firefox team is currently conducting further investigations with the QA team based on these reports.
This month we hosted Erik Nordin, Marco Castelluccio, and Greg Tatum from the Firefox Translations team for a virtual interview. We covered topics such as how the Firefox translation feature works, privacy features, incorporating LLMs and AI, and more. The stream recording will be available to view at any time. You can watch the recording on Air Mozilla or YouTube.
Please provide your feedback on this event through this form so we can make our future events even better!
In June we also hosted a Pontoon demo, which covers all the basic functionality you’ll need to get started translating on Pontoon, plus handy tips and tricks to help you get the most out of this easy to use tool.
March 31, or “three thirty-one,” is something of a talisman in the Mozilla community. It’s the date that, back in 1998, Mozilla first came into being — the date that we open-sourced the Netscape code for the world to use.
This year, “three thirty-one” is especially meaningful: It’s Mozilla’s 25 year anniversary.
A lot has changed since 1998. Mozilla is no longer just a bold idea. We’re a family of organizations — a nonprofit, a public benefit-corporation, and others — that builds products, fuels movements, and invests in responsible tech.
And we’re no longer a small group of engineers in Netscape’s Mountain View office. We’re technologists, researchers, and activists located around the globe — not to mention tens of thousands of volunteers.
But if a Mozillian from 1998 stepped into a Mozilla office (or joined a Mozilla video call) in 2023, I think they’d quickly feel something recognizable. A familiar spirit, and a familiar set of values.
When Mozilla open-sourced our browser code 25 years ago, the reason was the public interest: We wanted to spark more innovation, more competition, and more choice online. Technology in the public interest has been our manifesto ever since — whether releasing Firefox 1.0 in 2004, or launching Mozilla.ai earlier this year.
Right now, technology in the public interest seems more important than ever before. The internet today is deeply entwined with our personal lives, our professional lives, and society at large. The internet today is also flawed. Centralized control reduces choice and competition. A focus on “engagement” magnifies outrage, and bad actors are thriving.
Right now — and over the next 25 years — Mozilla can do something about this.
Mozilla’s mission and principles are evergreen, and we will continue to evolve to meet the needs and challenges of the modern internet. How people use the internet will change over time, but the need for innovative products that give individuals agency and choice on the internet is a constant. Firefox has evolved from a faithful and efficient render of web pages on PCs to a cross-platform agent that acts on behalf of the individual, protecting them from bad actors and surveillance capitalists as they navigate the web. Mozilla has introduced new products, such as Firefox Relay and Mozilla VPN, to keep people’s identity protected and activity private as they use the internet. Mozilla is contributing to healthy public discourse, with Pocket enabling discovery of amazing content and the mozilla.social Mastodon instance supporting decentralized, community-driven social media.
We’re constantly exploring ways to apply new technologies so that people feel the benefits in their everyday lives, as well as inspire others to responsibly innovate on behalf of humanity. As AI emerges as a core building block for the future of computing, we’ll turn our attention in that direction and ask: How can we make products and technologies like machine learning work in the public interest? We’ve already started this work via Mozilla.ai, a new Mozilla organization focusing on a trustworthy, independent, and open-source AI ecosystem. And via the Responsible AI Challenge, where we’re convening (and funding) bright people and ambitious projects building trustworthy AI.
And we will continue to champion public policy that keeps the internet healthy. There is proposed legislation around the world that seeks to maintain the internet in the public interest: the Platform Accountability and Transparency Act (PATA) in the U.S., the Digital Services Act (DSA) in the EU. Mozilla has helped shape these laws, and we will continue to follow along closely with their implementation and enforcement.
On this “three thirty-one,” I’m realistic about the challenges facing the internet. But I’m also optimistic about Mozilla’s potential to address them. And I’m looking forward to another 25 years of not just product, but also advocacy, philanthropy, and policy in service of a better internet.
As Mozilla reaches its 25th anniversary this year, we’re working hard to set up our ‘next chapter’ — thinking bigger and being bolder about how we can shape the coming era of the internet. We’re working to expand our product offerings, creating multiple options for consumers, audiences and business models. We’re growing our philanthropic and advocacy work that promotes trustworthy AI. And, we’re creating two new Mozilla companies, Mozilla.ai: to develop a trustworthy open source AI stack and Mozilla Ventures: to invest in responsible tech companies. Across all of this, we’ve been actively recruiting new leaders who can help us build Mozilla for this next era.
With all of this in mind, we are seeking three new members for the Mozilla Foundation Board of Directors. These Board members will help grow the scope and impact of the Mozilla Project overall, working closely with the Boards of the Mozilla Corporation, Mozilla.ai and Mozilla Ventures. At least one of the new Board members will play a central role in guiding the work of the Foundation’s charitable programs, which focuses on movement building and trustworthy AI.
What is the role of a Mozilla board member?
I’ve written in the past about the role of the Board of Directors at Mozilla.
At Mozilla, our board members join more than just a board, they join the greater team and the whole movement for internet health. We invite our board members to build relationships with management, employees and volunteers. The conventional thinking is that these types of relationships make it hard for executives to do their jobs. We feel differently. We work openly and transparently, and want Board members to be part of the team and part of the community.
Mozilla is a rare organization. We’re activists for a better internet, one where individuals and societies benefit more from the effects of technology, and where competition brings consumers choices beyond a small handful of integrated technology giants.
We’re activists who champion change by building alternatives. We build products and compete in the consumer marketplace. We combine this with advocacy, policy, and philanthropic programs connecting to others to create change. This combination is rare.
It’s important that our Board members understand all this, including why we build consumer products and why we have a portfolio of organizations playing different roles. It is equally important that the Boards of our commercial subsidiaries understand why we run charitable programs within Mozilla Foundation that complement the work we do to develop products and invest in responsible tech companies.
What are we looking for?
At the highest level, we are seeking people who can help our global organization grow and succeed — and who ensure that we advance the work of the Mozilla Manifesto over the long run. Here is the full job description: https://mzl.la/MofoBoardJD2023
There are a variety of qualities that we seek in all Board members, including a cultural sense of Mozilla and a commitment to an open, transparent, community driven approach. We are also focused on ensuring the diversity of the Board, and fostering global perspectives.
As we recruit, we typically look to add specific skills or domain expertise to the Board. Current examples of areas where we’d like to add expertise include:
Mission-based business — experience creating, running or overseeing organizations that combine public benefit and commercial activities towards a mission.
Global, public interest advocacy – experience leading successful, large-scale public interest advocacy organizations with online mobilization and shaping public discourse on key issues at the core.
Effective ‘portfolio’ organizations – experience running or overseeing organizations that include a number of divisions, companies or non-profits under one umbrella, with an eye to helping the portfolio add up to more than the sum of its parts.
Finding the right people who match these criteria and who have the skills we need takes time. Board candidates will meet the existing board members, members of the management team, individual contributors and volunteers. We see this as a good way to get to know how someone thinks and works within the framework of the Mozilla mission. It also helps us feel comfortable including someone at this senior level of stewardship.
We want your suggestions
We are hoping to add three new members to the Mozilla Foundation Board of Directors over the next 18 months. If you have candidates that you believe would be good board members, send them to msurman@mozillafoundation.org. We will use real discretion with the names you send us.
Mozilla is a global community that is building an open and healthy internet. We do so by building products that improve internet life, giving people more privacy, security and control over the experiences they have online. We are also helping to grow the movement of people and organizations around the world committed to making the digital world healthier.
As we grow our ambitions for this work, we are seeking new members for the Mozilla Foundation Board of Directors. The Foundation’s programs focus on the movement building side of our work and complement the products and technology developed by Mozilla Corporation.
What is the role of a Mozilla board member?
I’ve written in the past about the role of the Board of Directors at Mozilla.
At Mozilla, our board members join more than just a board, they join the greater team and the whole movement for internet health. We invite our board members to build relationships with management, employees and volunteers. The conventional thinking is that these types of relationships make it hard for the Executive Director to do his or her job. I wrote in my previous post that “We feel differently”. This is still true today. We have open flows of information in multiple channels. Part of building the world we want is to have built transparency and shared understandings.
It’s worth noting that Mozilla is an unusual organization. We’re a technology powerhouse with broad internet openness and empowerment at its core. We feel like a product organization to those from the nonprofit world; we feel like a non-profit organization to those from the technology industry.
It’s important that our board members understand the full breadth of Mozilla’s mission. It’s important that Mozilla Foundation Board members understand why we build consumer products, why it happens in the subsidiary and why they cannot micro-manage this work. It is equally important that Mozilla Corporation Board members understand why we engage in the open internet activities of the Mozilla Foundation and why we seek to develop complementary programs and shared goals.
What are we looking for?
Last time we opened our call for board members, we created a visual role description. Below is an updated version reflecting the current needs for our Mozilla Foundation Board.
Here is a short explanation of how to read this visual:
In the vertical columns, we have the particular skills and expertise that we are looking for right now. We expect new board members to have at least one of these skills.
The horizontal lines speaks to things that every board member should have. For instance, to be a board member, you should have to have some cultural sense of Mozilla. They are a set of things that are important for every candidate. In addition, there is a set of things that are important for the board as a whole. For instance, international experience. The board makeup overall should cover these areas.
The horizontal lines will not change too much over time, whereas the vertical lines will change, depending on who joins the Board and who leaves.
Finding the right people who match these criteria and who have the skills we need takes time. We hope to have extensive discussions with a wide range of people. Board candidates will meet the existing board members, members of the management team, individual contributors and volunteers. We see this as a good way to get to know how someone thinks and works within the framework of the Mozilla mission. It also helps us feel comfortable including someone at this senior level of stewardship.
We want your suggestions
We are hoping to add three new members to the Mozilla Foundation Board of Directors over the next 18 months. If you have candidates that you believe would be good board members, send them to msurman@mozillafoundation.org. We will use real discretion with the names you send us.
A couple of weeks ago the Localization Team at Mozilla released the Fluent Syntax specification. As mentioned in our announcement, we already have over 3000 Fluent strings in Firefox. You might wonder how we introduced Fluent to a running project. In this post I’ll detail on how the design of Fluent plays into that effort, and how we pulled it off.
Fluent’s Design for Simplicity
Fluent abstracts away the complexities of human languages from programmers. At the same time, Fluent makes easy things easy for localizers, while making complex things possible.
When you migrate a project to Fluent, you build on both of those design principles. You will simplify your code, and move the string choices from your program into the Fluent files. Only then you’ll expose Fluent to localizers to actually take advantage of the capabilities of Fluent, and to perfect the localizations of your project.
Fluent’s Layered Design
When building runtime implementations, we created several layers to tightly own particular tasks.
Fluent source files are parsed into Resources.
Multiple resources are aggregated in Bundles, which expose APIs to resolve single strings. Message and Term references resolve inside Bundles, but not necessarily inside Resources. A Bundle is associated with a single language, as well as fallback languages for i18n libraries.
Language negotiation and language fallback happen in the Localization level. Here you’d implement that someone looking for Frisian would get a Frisian string. If that’s missing or has a runtime problem, you might want to try Dutch, and then English.
Bindings use the Localization API, and integrate it into the development stack. They marshal data models from the programming language into Fluent data models like strings, numbers, and dates. Declarative bindings also apply the localizations to the rendered UI.
Invest in Bindings
Bindings integrate Fluent into your development workflow. For Firefox, we focused on bindings to generate localized DOM. We also have bindings for React. These bindings determine how fluent Fluent feels to developers, but also how much Fluent can help with handling the localized return values. To give an example, integrating Fluent into Android app development would probably focus on a LayoutInflator. In the bindings we use at Mozilla, we decided to localize as close to the actual display of the strings as possible.
If you have declarative UI generation, you want to look into a declarative binding for Fluent. If your UI is generated programmatically, you want a programmatic binding.
The Localization classes also integrate IO into your application runtime, and making the right choices here has strong impact on performance characteristics. Not just on speed, but also the question of showing untranslated strings shortly.
Migrate your Code
Migrating your code will often be a trivial change from one API to another. Most of your code will get a string and show it, after all. You might convert several different APIs into just one in Fluent, in particular dedicated plural APIs will go away.
You will also move platform-specific terminology into the localization side, removing conditional code. You should also be able to stop stitching several localized strings together in your application logic.
As we’ll go through the process here, I’ll show an example of a sentence with a link. The project wants to be really sure the link isn’t broken, so it’s not exposed to localizers at all. This is shortened from an actual example in Firefox, where we link to our privacy policy. We’ll convert to DOM overlays, to separate localizable and non-localizable aspects of the DOM in Fluent. Let’s just look at the HTML code snippet now, and look at the localizations later.
Last but not least, we’ll want to migrate the localizations. While migrating code is work, losing all your existing localizations is just outright a bad idea.
For our work on Firefox, we use a Python package named fluent.migrations. It’s building on top of the fluent.syntax package, and programmatically creates Fluent files from existing localizations.
It allows you to copy and paste existing localizations into a Fluent string for the most simple cases. It also concats several strings into a single result, which you used to do in your code. For these very simple cases, it even uses Fluent syntax, with specialized global functions to copy strings.
Then there are a bit more complicated tasks, notably involving variable references. Fluent only supports its built-in variable placement, so you need to migrate away from printf and friends. That involves firstly normalizing the various ways that a printf parameter can be formatted and placed, and then the code can do a simple replacement of the text like %2$S with a Fluent variable reference like {user-name}.
We also have logic to read our Mozilla-specific plural logic from legacy files, and to write them out as select-expressions in Fluent, with a variant for each plural form.
These transforms are implemented as pseudo nodes in a template AST, which is then evaluated against the legacy translations and creates an actual AST, which can then be serialized.
Concluding our example, before:
<ENTITY msg-start "This is a link to an ">
<ENTITY msg-middle "example">
<ENTITY msg-end ".">
After:
msg = This is a link to an <a data-l10n-name="msg-link">example</a> site.
Find out more about this package and its capabilities in the documentation.
Given that we’re OpenSource, we also want to carry over attribution. Thus our code not only migrates all the data, but also splits the migration into individual commits, one for each author of the migrated translations.
Once the baseline is migrated, localizers can dive in and improve. They can then start using parameterized Terms to adjust grammar, for example. Or add a plural form where English didn’t need one. Or introduce a platform-specific terminology that only exists in their language.
Gerv was Mozilla’s first intern. He arrived in the summer of 2001, when Mozilla staff was still AOL employees. It was a shock that AOL had allocated an intern to the then-tiny Mozilla team, and we knew instantly that our amazingly effective volunteer in the UK would be our choice.
When Gerv arrived a few things about him jumped out immediately. The first was a swollen, shiny, bright pink scar on the side of his neck. He quickly volunteered that the scar was from a set of surgeries for his recently discovered cancer. At the time Gerv was 20 or so, and had less than a 50% chance of reaching 35. He was remarkably upbeat.
The second thing that immediately became clear was Gerv’s faith, which was the bedrock of his response to his cancer. As a result the scar was a visual marker that led straight to a discussion of faith. This was the organizing principle of Gerv’s life, and nearly everything he did followed from his interpretation of how he should express his faith.
Eventually Gerv felt called to live his faith by publicly judging others in politely stated but damning terms. His contributions to expanding the Mozilla community would eventually become shadowed by behaviors that made it more difficult for people to participate. But in 2001 all of this was far in the future.
Gerv was a wildly active and effective contributor almost from the moment he chose Mozilla as his university-era open source project. He started as a volunteer in January 2000, doing QA for early Gecko builds in return for plushies, including an early program called the Gecko BugAThon. (With gratitude to the Internet Archive for its work archiving digital history and making it publicly available.)
Gerv had many roles over the years, from volunteer to mostly-volunteer to part-time, to full-time, and back again. When he went back to student life to attend Bible College, he worked a few hours a week, and many more during breaks. In 2009 or so, he became a full time employee and remained one until early 2018 when it became clear his cancer was entering a new and final stage.
Gerv’s work varied over the years. After his start in QA, Gerv did trademark work, a ton of FLOSS licensing work, supported Thunderbird, supported Bugzilla, Certificate Authority work, policy work and set up the MOSS grant program, to name a few areas. Gerv had a remarkable ability to get things done. In the early years, Gerv was also an active ambassador for Mozilla, and many Mozillians found their way into the project during this period because of Gerv.
Gerv’s work life was interspersed with a series of surgeries and radiation as new tumors appeared. Gerv would methodically inform everyone he would be away for a few weeks, and we would know he had some sort of major treatment coming up.
Gerv’s default approach was to see things in binary terms — yes or no, black or white, on or off, one or zero. Over the years I worked with him to moderate this trait so that he could better appreciate nuance and the many “gray” areas on complex topics. Gerv challenged me, infuriated me, impressed me, enraged me, surprised me. He developed a greater ability to work with ambiguity, which impressed me.
Gerv’s faith did not have ambiguity at least none that I ever saw. Gerv was crisp. He had very precise views about marriage, sex, gender and related topics. He was adamant that his interpretation was correct, and that his interpretation should be encoded into law. These views made their way into the Mozilla environment. They have been traumatic and damaging, both to individuals and to Mozilla overall.
The last time I saw Gerv was at FOSDEM, Feb 3 and 4. I had seen Gerv only a few months before in December and I was shocked at the change in those few months. Gerv must have been feeling quite poorly, since his announcement about preparing for the end was made on Feb 16. In many ways, FOSDEM is a fitting final event for Gerv — free software, in the heart of Europe, where impassioned volunteer communities build FLOSS projects together.
To memorialize Gerv’s passing, it is fitting that we remember all of Gerv — the full person, good and bad, the damage and trauma he caused, as well as his many positive contributions. Any other view is sentimental. We should be clear-eyed, acknowledge the problems, and appreciate the positive contributions. Gerv came to Mozilla long before we were successful or had much to offer besides our goals and our open source foundations. As Gerv put it, he’s gone home now, leaving untold memories around the FLOSS world.
The art of localizing a piece of software with a Yes button is to know what that button will do. This is an example of software UI that makes assumptions on language that hold for English, but might not for other languages. A more frequent example in both UI and languages that are affecting is piecing together text and UI controls:
In the localization tool, you’ll find each of those entries as individual strings. The localizer will recognize that they’re part of one flow, and will move fragments from the shared string to the drop-down as they need. Merely translating the individual segments is not going to be a proper localization of that piece of UI.
If we were to build a rule-based machine localization system, we’d find rules like
gaelic-yes:
If the title of your dialog contains a verb, localize Yes by translating the found verb.
pieced-ui:
For each variant,
Piece together the fragments of English to a single sentence
Translate the sentences into the target language
Find shared content in matching positions to the original layout
Split each translated fragment, and adjust the casing and spacing
Map the subfragments to the localization of the English individual fragments
Map the shared fragment to the localization of the English shared fragment
Now that’s rule-based, and it’d be tedious to maintain these rules. Neural Machine Translation (NMT) has all the buzz now, and Machine Learning in general. There is plenty of research that improves how NMT systems learn about the context of the sentence they’re translating. But that’s all text.
It’d be awesome if we could bring Software Analysis into the mix, and train NMT to localize software instead of translating fragments.
For Firefox, could one train on English and localized DOM? For Android’s XML layout, a similar approach could work? For projects with automated screenshots, could one train on those? Is there enough software out there to successfully train a neural network?
Do you know of existing research in this direction?
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 ChairmanTom Wheeler; RepresentativeRo Khanna; Mozilla Chief Legal and Business OfficerDenelle 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; andDane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated byGigi 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.
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.
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
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:
elmo
MySQL
ElasticSearch
RabbitMQ
Mercurial upstream repositories
Mercurial web server
a10n get-pushes poller
a10n data ingestion worker
Buildbot master
Buildbot slave
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-composetest 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
Anyone got taskcluster running on something resembling docker-compose for local testing and development? You know, to get off of buildbot.
Initial setup steps for the docker-compose staging environment are best done … ?
Test https connections in docker-compose? Can I? Which error cases would that cover?
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:
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.
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
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
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.
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
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.
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.
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.
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:
Feature-freeze and string-freeze are on migration day from central to aurora
Features not making the freeze take the next train
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.
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.
