This is the second post in a series of three posts on Next-Generation Web Localization at Mozilla. If you haven’t read it, please start with the first post. Again, this is a discussion starter and nowhere close to a final decision. Your opinion on the issue is very valuable, so please leave comments.
In yesterday’s post, I described the problem we are facing with an increasing amount of localizable websites under the roof of the Mozilla project. In short, I concluded that getting more possible localizers involved is a way to solve this — but scaling the localizer community has to happen in a healthy way.
Engaging an arbitrary amount of people in solving a problem even has a fancy buzz-word nowadays: “crowd-sourcing”. But is this what we want for the L10n community? Increasing the sheer amount of translations is not going to help anyone, unless they are good translations. In other words, we want more signal, not more noise.
In addition, when improving Web L10n, one rule is the most important: Don’t break what works. We have an amazing group of localizers who are indispensable and it would be foolish to demote them to some sort of “translation monkeys”. Likewise, merely shifting their work from actual localization to the tedious task of approving “crowd-sourced” strings one by one is not going to make their lives any easier or more fun.
Scaling Locale Ownership: Hierarchies
One possible way to tackle this dilemma is what we could call “hierarchical community management”. One or more locale owners should be able to delegate localization authority for one or more projects to a set of other localizers. These contributors can, in turn, either localize a particular project themselves or decide to pass on localization rights in a similar way, with or without the need to sign off on the changes their respective delegates perform. By making the whole process opt-in and as fine or coarse-grained as the localizers desire, it is ensured that for one locale, a small group of very active people can cover it all, while for another locale, the work can be spread over a substantial number of shoulders.
With a hierarchical permission system, delegating work to known localizers is not the only thing getting easier. It gives newcomers a very structured way of entering the L10n world in the limits of a single project or two, and to “climb up the tree” by building reputation in the community.
But what are good translations? — Building a Reputation Model
You might have noticed, for approving translations from other people, the per-project localizers will still have to read and accept a possibly huge amount of translations. This is not only tedious, it may also take longer than just translating things oneself. Therefore, when building a foundation for next-generation Web L10n, reputation should not only be assignable by “admins”, but also earnable from within the system.
A good example of such a system is Yahoo Answers, an online Q+A/advice community. They do not only give you points for contributing (i.e., adding to either “noise” or “signal”), but users are also able to “thumbs up” or “thumbs down” individual contributions, therefore dividing noise from signal. If we give localizers the opportunity to approve contributions in bulk that were added by a trusted individual or based on a specific thumbs up/down level determined by the community, it’ll be a powerful tool for involving more contributors without decreasing the translation quality. If we, in turn, give the contributors a measurement of reputation for submitting successfully approved translations, they are able to build a tangible reputation level that’ll facilitate their advancement in the L10n community.
On an organizational level, next-generation Web L10n needs to be based on a flexible, hierarchical community structure that retains strong locale ownership in order to ensure a high level of quality, but at the same time enables and encourages “newcomers” to build a tangible reputation in the community.
Photo Credit: “pronouncing dictionary”, CC by licensed by Muffet on flickr.