In my previous blog post, I summarized the transition through which Mozilla project went and how it applies on how local Mozilla communities. I explicitly mentioned enormous growth of Mozilla ecosystem, diversification of products & projects, and differentiation of project development patterns which results in different requirements for marketing, QA, support, localization etc.
Now, I’d like to expand on how I believe our local communities now operate.
On Local Community Workload
The result of this growth of Mozilla ecosystem is a rise in a workload that our local communities experience. With this work comes the challenge to communicate to locales the richness of Mozilla on a local ground. It seems that localizer workload is mounting high and local communities are trying to find ways to adapt, because:
First, it is not scalable to manage all Mozilla localizations by the team of a size that fit the needs 5 years ago.
Second, localizers are not the only type of people that exist in a local community. There are various tasks which require different skills and different people may find different sorts of motivation to work on different aspects of Mozilla.
It’s pretty easy to get out of balance and try to take more than you can handle when there’s so much going on and you feel in charge of your locale. Some communities are more successful finding their way, some are struggling.
I believe we have to adjust our approach to this new reality.
My opinion on the role of l10n-drivers
Traditionally, a lot of the local engagement work has fallen on the plate of localizers. The L10n-drivers team then becomes very important in helping local communities manage their workload. Having participated as an l10n-driver for over one year now, I see how the team became crucial in supporting communities in several ways. It:
- It makes sure that when we call out for localizations, what you localize will be used for a long time to improve maximum work/value balance.
- Builds tools that reduce the entry barrier and time spent by localizers on localization and local management tasks around
- Provides information on projects, their roadmaps, goals and results (metrics) to help localizers make informative decisions on what to localize and when.
- Supports localizers in solving localization blockers like hardcoded strings, or untranslatable strings to make the results of their work worth the time their spent and that if they want, they can fully localize the product and make it look awesome and natural in their language. (read: one untranslatable string ruins hard work and is a great way to demotivate anyone)
- Helps adjust roadmaps of projects to minimize the overlap between relases to spread the workload in time.
But, the role of local communities has expanded far beyond just localization. Our team’s work will not be enough and I think that we have to revise assumptions we all make about what is localization process, and what are our goals.
My opinion of the changing role of Localizers
Localization of Mozilla today is not a single, homogeneous task like it used to be. There are different tasks to take and different people who want to contribute. Some tasks require short spikes of attention once per year (around release), other require bi-weekly contribution, other have no release schedules and just take any contribution. It all requires different amount of energy, focus, attention and time.
And the core goal of localization – to bring the product closer to your local ground – is suddenly becoming a complex toolset. With so many projects to choose from, local communities should stop thinking about them as a single bundle. Instead we should all start recognizing that this diversification allows us to pick what we need.
You, local community members, are the best positioned to make the right decision on which projects are needed in your region. We cannot assume that each region needs the same amount of Mozilla ingredients.
By that I mean not only ability to pick up projects to localize for your region, but also deciding, together with the project leaders, how much of the project should be translated, and what kind of adjustments are required for your culture. It’s extremely important to understand, that sometimes you cannot localize everything, although we all know how much satisfaction we have from “collecting it all“. Sometimes “top10” articles gives better result than “try to figure out how to translate it all“. And sometimes you need to go beyond translation. The “top10” SUMO articles in English may be different than “top10” in your locale, and maybe some aspects of marketing campaign could resonate better in your country if you adjust it to your culture and reality.
Armed with this power, local communities can pick the projects that best resonate with what is needed to promote Mozilla vision in their region and put more effort in those. It’s a great power, and a great responsibility, and we have to trust local communities that they know better than any centralized decision making system can ever know, what is important. And we, owners and peers of the projects have to help local communities make the right choices, and fine tune the ingredients they picked. You, local communities, are in charge here.
With so many tasks, evangelism, marketing, PR, QA, development, support, localization, that are represented in Mozilla, it may be very challenging to fulfill them all by localization team. Many local communities are working on various aspects of Mozilla project, and what’s common to them, is their regional identity and proximity which allows them to support one another, share resources and find new contributors. I believe it’s crucial to preserve the local identity and that there is a great value for each contributor from around the world to peer with other contributors working on other aspects of Mozilla in their region, but localization is not the only task out there.
And more than ever, we need local communities to cooperate with Mozilla project leaders to find new contributors and grow the communities. Generating new project that attract new contributors is one of the key aspects of a healthy, sustainable ecosystem and it’s true for both, Mozilla project as a whole, and for Mozilla local communities.
In the last part, I’ll try to summarize the state change and give you some ideas to consider.