The Inescapable Logic of Language Localization
Machine translation tools have been shown to be quite effective at translating certain types of text, but "you almost certainly can't use a tool like that for customer software -- not unless your main aim is to alienate your potential customers," said Translate House CEO Dwayne Bailey. However, "you might succeed in creating an international meme like, 'All your base are belong to us.'"
05/20/14 7:57 PM PT
Tailoring language translations for software documentation and graphical user interfaces can make or break an open source project. Localizing language is a unique undertaking, with a number of moving parts.
Developers often have to choose between tight development cycles or less harried ones that might let competitors advance first. The process of translating language in releases for different target markets can be a complicated part of the developmental process. It presents costly cultural and language translation barriers that often are beyond the financial abilities of the open source community.
Smaller open source projects often lack the manpower or financial support to apply human editing to translations. The only option is to rely on machine translation services. That solution often delivers poor, even embarrassing, results.
The same language and cultural barriers open source developers face with multilanguage software documentation are also present in localizing websites. Poorly handled translations can very quickly give potential software users a glaring impression of amateurism.
The software project might be a fantastic product. Still, first impressions formed by language translation goofs are difficult to change.
Typically, software developers get more than 50 percent of their revenue from non-English speaking countries, according to Renato Beninatto, chief marketing officer and vice president of marketing and business development at Moravia
"If you want to convince somebody to buy your product, you have to speak to them in their own language," Beninatto told LinuxInsider.
How to localize language translations effectively on the cheap is a particular problem for open source software developers, said Ian Henderson, chief technology officer and cofounder of Rubric.
"The open source industry is very different. The communities rely on volunteers. They are very enthusiastic about the product. But they are not necessarily linguists. Oftentimes, they have no idea what is required to industrialize the process," he told LinuxInsider.
Most open source projects lack the financial ability to provide the same level of commercial language translation work that proprietary software developers purchase. The process is an industrial one that requires more than in-house workers from a development community usually can handle, Henderson noted.
With the software market stretching worldwide, developers have to consider staggering numbers of documentation and program translations. The difference between open source developers and proprietary developers is not the volume, but the ability to pay for scale.
For example, Rubric localizes languages for big brands the likes of Microsoft as well as large open source projects. Rubric translates into 135 languages, said Henderson.
Moravia works with commercial software developers and large open source projects such as Mozilla's Firefox Web browser. Moravia translates software and documentation into 110 languages, said Beninatto.
"Traditionally software was developed in a waterfall fashion. Products were dropped every few months in another language. Now the pace is much faster, and multiple languages are translated at once. So working with even 50 languages becomes very challenging," he added.
Getting a few multilanguage speakers to translate blindly from one language into another accomplishes very little. That does no better than a machine translation. Both can be ineffective and troublesome.
The first step in the process is to look at what the software is about, said Henderson. Then the translation manager identifies the linguist who has the relevant domain expertise.
"In the open source community that is less of an issue, because the people who volunteer often have an interest in the product," he noted, "but the lack of linguistic expertise often results in bad grammar and typos."
The next step is to write instructions for the translators, according to Henderson. This involves describing what the software is about. In addition, providing essential cultural notes and language requirements solves the biggest problem that translators have -- lack of context.
Two other elements in the process are the compilation of a glossary and a style guide to provide translators with a set of generic instructions about how the writing should be addressed. The glossary may contain 100 to 200 key terms that keep cropping up so the translators can use them consistently.
Where in the World Is...
The essential ingredient in localizing language use in software and documentation is geography, noted Moravia's Beninatto. You have to involve multiple people in multiple geographies.
Translations are not a development core task. So language conversions can not be done by the same set of multilingual workers in a central office.
"The in-house model was very popular n the 1980s and early 1990s, but with the growth of software's popularity it became an unsustainable model. You can not translate in-house with people who do not speak the target languages," said Beninatto.
One of the biggest challenges today is how to deal with the increased speed of development, he added. You move from drops to drips. Plus the time frame is compressed into hours or a few days.
Making effective localizations of language translations is far from the word-for-word substitution approach. That is what machine translations and services like Google Translate provide.
The language translators have to incorporate the proper cultural tone into the content, which is something automated translations can not do.
"The translations come out broken. The results will create embarrassments. It creates meaningless phrases or stupid statements, said Beninatto.
Cultural nuances must be taken into account. South Africans in general are pretty laid back, for example, so the language style of a translation might be relatively casual. However, for a translation aimed at German users, it would not be advisable to use an overly friendly tone.
"The German clientèle requires a style that is much more formal," explained Henderson. "The style and tone of the language translation depends on who your target market is. You are doing more than a literal translation. You are infusing a cultural awareness in the documentation and its language usage to fit what the culture is."
Another factor language translators must adjust in the software screen views and documentation is the accuracy of geographic and local information, both of which make a product more valuable.
Four things are different in every geography: Date format, decimal separators, currency signs and time format are specific to each language. These things have to be localized in software, along with the other language nuances.
"This is called 'internationalizing the product.' It is something that is done before localization," said Beninatto.
Even things like colors have different meanings in different cultures. For instance, in some cultures white is associated with cleanliness, but in Japan yellow has that association.
Using colors inappropriately can cause miscommunication. For instance, Beninatto's corporate documents show his signature written in red ink. However, in China, displaying a name in red ink signifies that the person so named is dead. It's important to consider the context in which the target culture will interpret information.
No Small Issue
The language translation service industry is a very big deal. The commercial space has a lot of competition. The official count is that there are at least 30,000 providers worldwide, according to Henderson -- but not so big for open source developers.
"In the open source space, it is much more difficult. There are not that many commercial providers who see any interest in providing support for the open source community because it costs money. That is a big disincentive to get involved," Henderson pointed out.
For small open source projects, the only hope for effective software localization might rest in the skills and willingness of a dedicated community -- but it still is a necessity for survival.
Machine Translations Don't Speak the Lingo
Open source projects that must rely on automated translations to localize their language reach need to use those programs very carefully, advised Dwayne Bailey, CEO of Translate House and research director for the African Network for Localization.
Machine translation tools have been shown to be quite effective at translating text that follows a limited grammatical structure and limited vocabulary and is straightforward -- like a car maintenance manual, for example. Tools like Google Translate are great to get an idea of what someone has said in a newspaper article or to get a sense of what a page means, Bailey told LinuxInsider, "but you almost certainly can't use a tool like that for customer software -- not unless your main aim is to alienate your potential customers."
However, "you might succeed in creating an international meme with translations like, 'All your base are belong to us,'" he quipped.
Technical and Linguistic Rarely Mix
Software developers and website designers might get acceptable results doing language translations in-house rather than using commercial translation firms, but the risks for failure are far greater, Bailey cautioned.
It really does depend. If you have the skills in-house, then you can achieve a lot in-house -- but then you need to manage the whole process, both technical and linguistic. Most companies seriously underestimate the challenges, he said.
"A commercial vendor brings a wide range of experience and a wealth of tested translators. They buffer you from the unmeasured cost, the cost of getting it wrong," he said.
"Localization is, in my view, absolutely vital," Steve Jones, software developer and creator of Blue Pup Linux, told LinuxInsider.
The use of Linux, particularly in Asia, Africa and the Pacific region, appears to be ramping up. This growth is driven by the often combined burdens of poverty and disability, he said.
"That is contributing to the growth of Linux projects such as the Puppy Linux distributions. Given its spread, I think that community volunteers will suffice, provided that nothing too technical is asked of them," he concluded.
Software localization can make or break the success of any software product. It matters little if the product is proprietary or open source, noted Bailey. The language localization process is a challenge for proprietary software makers as well.
"Again, success depends on the product," he said, "but today we have a growing number of consumers that are using computers and devices in languages other than English. If you want to reach those consumers and compete, then you have very little choice but to localize your product."