When I find myself puzzling over some community issue in the localization world, the first person I turn to for help is Jeff Beatty, head of localization at Mozilla. Beatty is multitalented and has a wealth of experience in a variety of aspects of the language industry. In addition to his experience in the corporate world, he is an adjunct professor at Brigham Young University teaching a course on translation technology. His work as an active volunteer and collaborator in many different translation projects and his fervent advocacy of open source as a force of positive community impact have given him a much-valued and sought-after expertise in community translation. The BBC and The Economist have interviewed him focusing on community localization practices in open source for under-resourced languages. Aside from his professional attainments, Beatty exudes a level of passion in community affairs that is hard to equal.

Given his expertise in language and technology and the broad experience he brings to the community table, Beatty is well placed, perhaps uniquely so, to provide insights into the shortcomings of the tools and techniques we currently use. Across the localization board, there are numerous applications that facilitate our work as translators, localizers and so on. While we all have our favorites, we still have to resort to workarounds. In other words, for all the tools at our disposal, there is no single app that covers all requirements. Is such an all-singing, all-dancing app a pipe dream? We won’t know until we muster our community and unite it in a common purpose of working toward it. The ingenuity that open source developers show suggests that it’s worth fixing on this lofty goal. However, that must be predicated on increasing the efficiency within the community in order to bring members together with the purpose of harnessing the maximum potential each member has.

In the following paragraphs, Beatty lays out his vision of a way of maximizing the impact our community can have. It’s a challenging task, but since when did the language industry falter in our endeavor to facilitate communication between people across the globe?

Wish list for a community localization roadmap

The cornerstone of my career within the localization industry is community. After nine years in the industry, I’ve observed social translation and localization go from a niche, experimental model for translating projects to a viable alternative to the traditional translation models for certain content. Within my role at Mozilla, I’ve trained volunteers from a wide range of backgrounds and expertise, from developers with a high level of technical expertise to budding linguists interacting with a translation platform for the first time. Being well versed in the community translation model, I have collected positive anecdote upon anecdote from people on both sides of the social translation process: the “client” organizations and the “supplier” community translators. I’m also keenly aware of the challenges each side faces. For buyers adding a community translation model to their translation processes, it can be challenging to move from the common “black box” mentality to a more people-centric mentality; and the translation technology we use can facilitate this transition or reinforce the traditional mentality. I believe that many of our common translation tools do the latter. Not that this is a bad thing: these tools have been developed according to the needs of language service clients, language service providers, and professional translators in a world where the operative currency, is literally currency. In the world of community translation, the operative currency is clout and a system based on clout exchange can vary from client to client and supplier to supplier. Because of this (among other reasons), both client and supplier in this model require a different approach to the traditional translation platform, specifically one that emphasizes the human involvement in the translation process in order to maximize the community’s participation and impact. Some of these features are specific to a community model, but they can also be very valuable to language service providers as they manage their own freelancer community. Rather than attempt to tell tool developers what features I believe need to be prioritized in their roadmaps, I’d like to offer something akin to a “user story” for community translation, broken up into five main points.

Do the basics so well that your users don’t notice

In coming up with a minimum viable product (MVP) for community translation clients and suppliers, look no further than the standard feature set we’ve all come to expect from translation platforms. Like professional translators, community translation clients and suppliers care about efficiency, quality and project-specific data. Standard features like translation editor, translation memory, terminology reuse, consistent document segmentation and target preview are expected to be present in a community translation MVP. As the world moves more toward cloud-based services, centralized translation assets in the cloud are gradually moving into the MVP space. Even machine translation is entering the MVP space for translation platforms.

While these feature sets are very familiar to all professionals in our industry, the way that they are integrated into the translation platform should be considered very differently from what a professional would come to expect. User-centered design advocates for an approach that doesn’t make the user think. This is especially true for community translation models. Where a professional might have the skill set necessary to diagnose places where their preferred translation platform isn’t functioning properly within one of these core features, the same should not be assumed for a volunteer. Clients and suppliers in a community translation model come from such a wide array of backgrounds that tool authors should not assume the same level of specialized knowledge as their traditional model counterparts.

The need for these features to work together seamlessly is higher for stakeholders engaged in a community translation model than a traditional model. Limiting the need for user intervention becomes one of the highest priorities. A concrete example of this is pretranslation: where a professional translator will expect to have control over how pre-translation functions, a community translation supplier will want that decision made for them, reducing their need to tell the software what to do.

Lower the learning curve to only the essentials

Now that we’ve established what an MVP for community translation clients and suppliers looks like, let’s build upon that by addressing the variety of people attracted to community translation projects. In my years working with communities, I’ve met core contributors who had a host of different day jobs. They’ve been software developers, primary school teachers, professional translators, students and former missionaries. This wide spectrum of skill sets, backgrounds and personalities requires that a translation tool finely attuned to the needs of the community would have the lowest barriers to entry. At Mozilla, we learned this through trial and error. For years, core contributors needed to understand how version control systems worked, along with command-line interfaces in order to make an impact. Now, our tools perform periodic bidirectional synchronization with our repositories so that our core contributors can focus their time where they have the most influence on translation and testing. Core contributors come to a project to have an impact — remember clout as currency? The more time spent learning to use a translation tool (or learning to use it incorrectly) is time spent away from the more impactful activity of translation.

Lowering the entry barrier can be done a number of different ways, many of them involving making decisions for the community. While this can be good for a number of things (such as automatic project preprocessing or automatically blocking badly localized strings within the translation editor in real time), the better route is to inform the community in a language they understand and provide as much context as possible. Informing the community can mean a lengthy tutorial on a project or a tool, but I recommend avoiding jargon-filled user interfaces (UIs). Using a more generalized language within a tool for a feature like translation memory helps to make the tool more accessible to all contributors, regardless of their background. While for many of us the term translation memory is obvious, it’s not so obvious to a primary school teacher or even a software developer. It may not even be obvious to a client organization. Avoiding jargon within a community translation platform UI will help client organizations recruit contributors and make their projects more accessible to communities.

We know from the traditional model of translation and localization that context is necessary to reduce the risk of producing a poor quality translation. Where this is true within the professional realm, it is doubly true within the community realm. Context-based features improve the community’s potential for impact and help to lower the learning curve to participating in a project. In-context translation is a great example of a feature that uses context to inform the decisions of the community translation supplier when they are executing the translation. In-context translation is easier for documents and web sites (thanks to document preview technology and text scraping), but it can be a challenge for software applications. The world of in-context translation for software UIs is coming, thanks to the advent of technology like run-time string delivery versus build-time string resource bundling. It will be very interesting to see how the translation platform developers adapt their tools to include in-context translation.

Improve team collaboration within translation platforms

This is a realm of features that have only recently begun to be manifest in translation platforms and are of critical importance to any international team or community: the ability to communicate with another contributor in real-time, within the translation environment. Robust communication features within the translation environment can help provide a safe space for asking questions, making comments, and can even provide a vertical communication channel between new members of a community, senior members of a community and the client organization’s project manager. It can also help community members to establish clout within their community and in the eyes of their organization by allowing them to more openly position themselves as the community’s resident expert. One reason community members need these features within the translation environment is that they want to remain engaged in the task of translating while being able to ask questions within the environment in the moment they need the answers. Instant messaging services help to accommodate this need, as well as an in-app inbox, and forum-like commenting linked to an individual translation unit.

One of the biggest reasons for adopting more robust communication services within a translation platform is quality. We live in an age where a translation from a community member can simply be accepted or rejected without expressed cause. This, unfortunately, does nothing to contribute to a contributor’s need to build clout in exchange for their participation. The contributor has no idea why the translation was accepted or rejected and often is not even notified in either case. This means that the direct link demonstrating their impact on a project can become vague. Additionally, because they don’t learn why a translation was accepted or rejected, they miss out on a valuable mentoring opportunity and positive feedback from their fellow community members, both of which contribute to a community translation supplier’s clout. These features build a more stable foundation within a community and incentivize contributors to remain with a project. As a result, the client organization decreases the quality risk of utilizing an amateur community for translation projects.

Use community metrics to recognize impact and measure quality

As a general rule, as a core contributor’s clout increases, so does the quality of their output.

At the point that they receive some form of clout, their name and reputation are tied to the quality of their output. Better quality output organically merits more clout, and thus engenders a deeper desire to produce high-quality output. Accumulating a profile of skill, ability and translation quality for individual contributors and communities ensures that an individual or a community’s clout is on display, for better or worse. Metrics on productivity, translation errors, ratio of accepted translations to rejected translations, technical translation proficiency (for example, no broken variables in a string), responsiveness to reviewing new translation submissions, all of these metrics combine to produce data that a community translation client can use to distribute clout for high impact performance from a community. Community translation suppliers would, ideally, be able to take this clout with them wherever they decide to volunteer. In my experience, many of them have a number of irons in the fire with other projects. Imagine how much quicker and easier onboarding a new volunteer would be if they brought with them their metrics and clout. Community translation clients often spend a lot of time evangelizing their cause and recruiting people to donate their time. In the current world, when a community translation supplier for one client project adds a project from another client to their list of community projects, they essentially begin the journey of building clout all over again. If the data were standardized and exchangeable, that would save clients’ time in the onboarding process and increase the impact of the clout the supplier has received in other projects.

Automate community engagement in order to scale

Community engagement can occupy a lot of the overhead cost for community translation clients. Between sending welcome emails, notifications, encouraging activity, responding to individual questions, training and mentoring newcomers, and giving recognition and clout — all of this can occupy a lot of a client’s time. So much time, in fact, that scaling to involving community translation suppliers in new languages risks failure of the whole program. Invariably, the first line of responsiveness to a scaling issue like this is the assumption that the client needs to hire more people. I would counter that our translation platforms could rise to the challenge of automating some of this overhead to make one client project manager’s impact on the community much greater.

Within the life cycle of a community translation supplier there are various event-driven milestones, such as creating an account in a translation platform and submitting the first translation. Most of the time, either the supplier receives no communication, they receive an automated response confirming that they’ve created an account (nothing more) or the client manager reaches out to say welcome and thank you for the first contribution. None of these currently solve our problem of successfully scaling community engagement for client managers. By automating communication for specific events within a supplier’s participation life cycle and attaching a client project manager’s name to the communication, we’re solving some of this problem. It should be possible to automate communication for most of these events. GitHub does it, why can’t translation platforms? If you submit your first translation, you get a thank you! If your ratio of accepted translations to rejected translations is above a specific level, you get a notice of receiving more privileges within the translation platform! If someone in your community has been inactive for six months, they get an email inviting them back. All of these events can be automated so that the supplier receives their deserved clout while the client can focus on the nuances of community management and making improvements to the client’s process.

Let’s also take this a step further: we should be able to automate supplier recognition beyond an email. Providing recognition for positive achievements is a critical component of the clout-based currency exchange. The most successfully I’ve seen this done is by a gamified user experience design that awards a digital badge when a supplier reaches a certain volume threshold of words submitted to the project. But it’s 2017; we can do better! Clout is exchanged through both intangibles and tangibles. Imagine if a translation platform could automatically detect when a supplier arrived at a particular achievement and then notify the client manager with suitable options for providing recognition. Imagine if that manager could simply select one of these options and the system took care of sending that recognition to the supplier. All of this, with the only manual intervention being that the manager selects an option for recognizing the good work of a supplier. That’s a translation platform that I’d want to use!