3 tips for localizing open source projects

No readers like this yet.
Participation text on a field

Opensource.com

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 organizations, 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 localize a project for a new market. Translating an open source project is a unique undertaking in many ways, with a number of moving pieces. Open source organizations and their communities need to do three things to make their solutions as accessible as possible: establish a guiding set of terms, a central contact and a set of criteria.

1. Consistency: establish a guiding set of terms

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 localized 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.

A guiding set of terms 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 this guiding set of terms 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. Communication: establish a central contact

Translating the website of the OSS to another language—without localizing 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 localized, too - from colors and images to in-program tutorials and instructions.

To organize this team effort, there needs to be a central contact, a project manager who can oversee the process. When translators and developers work together, 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.

The central contact can communicate changes 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 localized.

3. Testing: establish a set of criteria

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?

To answer these questions, a set of criteria has to be established. 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 localization. Without an organized 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.

With a set criteria in place, teams can determine which team members 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

Organization is the most important element of any OSS development project. Translation is no different. A community of volunteers needs to get together and first establish a guiding set of terms to guarantee accurate and consistent translation. A central contact should be appointed to keep these efforts organized and a set of criteria needs to be established when the final product is being tested.

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, organized 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.

 

Tags
Avatar
Ian Henderson is the chairman and CTO of global language service provider Rubric. He has a deep knowledge of globalization issues, technology and distributed team management. Prior to co-founding Rubric, he worked in various management and engineering positions at Siemens (Germany), Expert Software and Phoenix Software (New Zealand) and Berlitz (England).

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.