3 top tips for translating open source projects

By Ian Henderson and Jeff Beatty

Open source software (OSS) has had a huge impact on the development of technology today. From apps and web browsers to content management platforms and operating systems, there’s no doubt that open source projects have influenced the way that we create and access information.

Research shows that the open source trend is growing beyond the traditionally tech-focused market, too. A survey, conducted by BlackDuck Software and the Linux Collaboration Summit, found that within the next two to three years, government agencies, health and life sciences organisations, and media and finance businesses may all be making more use of open source products. Additionally, respondents said that they’re adopting more OSS development methods and fostering the growth of industry-specific communities.

As the demand for OSS grows across industries, the demand for OSS will grow globally, too. That often sparks conversations about how to localise a project for a new market. Translating an open source project is a unique undertaking in many ways, with a number of moving pieces. Here’s what open source organisations and their communities need to keep in mind as they work to make their solutions as accessible as possible.

1. Consistency is everything
Translating an open source project is much like the development of the project itself. Just as developers create a widget or a plugin for software, volunteer translators can each translate different pages and features, building localised software piece-by-piece. With a big enough community, translation can be a breeze, with dozens of people working to finish the project.

But anyone who has edited a Wikipedia page knows that within every community, there are a lot of competing visions. When a team of translators is assembled for an OSS product, the community first has to establish a central, guiding set of terms to make sure the process is streamlined.

This is critical when you’re building an open source project in a new language, because a universal reference cuts down on discrepancies in user experience. For example, if one translator uses the word “History” and another uses “Past” for browsing history, the end-user experience can become confusing. Likewise, the names for different functions and settings have to be accurately translated, or the product may be unusable.

A team needs to agree on terminology to help ensure the user experience is seamless. To that end, a collaborative, living document that has shared terms and potential stumbling blocks should be maintained during the translation process.

2. A programme is worth a thousand words
Translating the website of the OSS to another language – without localising the software itself – might encourage users to try the product, but it won’t get them to adopt it. The development and translation of OSS should be intertwined. The community of translators that comes together to translate OSS should work closely with developers. That way, other things can be localised, too – from colors and images to in-program tutorials and instructions.

That’s also the only way that FAQ and technical support pages can reflect the user experience as accurately as possible. If someone translates a support page and says that users should press the “OK” button, but the software is translated to have a “DONE” button, then users could end up feeling lost.

Translators should establish a centralised point-of-contact among developers, so that changes can be communicated across the whole team. Choose a channel that works best, too, whether that’s a forum, email or a social media group. That way, the latest updates and implementations stay visible, so the community can keep track of which things still need to be localised.

3. Comprehensive testing needs structure
Open source projects need to deliver users with a quality experience right out of the gate. But what features need to get tested? How do they get tested, and how many people test them out?

Translation complicates the testing process, because the software doesn’t just have to be tested for glitches; it has to be tested for context and localisation. Without an organised team, the testing has no structure. It can be difficult to say when something is or isn’t finished, which means release dates can keep getting pushed back further and further, with no end in sight.

The best way to test a newly translated, localised OSS product is to have set criteria in place to decide which teams test what pages. With the right kind of checklist, volunteers can go through the process step-by-step. Comprehensive, structured testing ensures that the product updates aren’t disruptive, and users will have a great experience.

Found in translation

Organisation is the most important element of any OSS development project. Translation is no different. A community of volunteers needs to get together and decide how to best localise a product before actually committing to any specific part of the project.

A team should designate different translators to different elements of the software. A universal reference guide for terminology has to be written to help streamline the actual translation, and developers should be contacted, so translators can coordinate and manage web and user interface changes accordingly.

OSS projects are as only as strong as the community around them. Bringing open source projects to new markets continues to strengthen and build on what already makes them great. By making sure that translation efforts are consistent, organised and structured, it’s possible to create a translation process from the ground up. New users can enjoy OSS products and, hopefully, become part of the community that started it in the future.