Subscribe

A universal language

Write software with translation in mind (or risk starting over).

Ian Henderson
By Ian Henderson, chairman and CTO, is co-founder of Rubric.
Johannesburg, 22 Oct 2014

All software with global ambitions, whether a standalone application or Web site, or the code that drives hardware (eg, a cash register), should be written with translation in mind.

If treated as an afterthought to be tackled once core functionality is finalised, translation can cause havoc with product releases, incurring debilitating costs, difficulty and delay.

Bad practice

Typically, first-time expansionist companies get to the quality assurance (QA) stage only to realise they haven't given any thought to 'internationalisation' (readying a product for different territories, including translation). No matter, they think, the hard work is done. How long can translation take?

Thus a rush ensues to correct matters. Unfortunately, it turns out the software was (wrongly) hard-coded to display temperature as 'x degrees'. In Turkey, temperature format is 'degrees x', which means the software will 'look funny', but nothing more serious than that. The dateline, however, is a bigger problem. '1.4.2014' might, according to different country conventions, mean April Fool's or 4 January. Big problem.

Or, horror of horrors, the product malfunctions or has display errors, due to careless, invasive translation.

It begins to dawn on the product team that a Pandora's Box of trouble has been opened. The core functions of their software, so sensitive to positioning, language and punctuation of every character, have been lost in translation thanks to a translation team with no appreciation for software engineering.

No quick fix

Picking up the pieces looms large, since the company doesn't know "what exactly the problem is" (it had never considered translatability of code), the extent of the problem, or what fixing it may entail or cost.

Commonly, it requires going back to the development team. However, at this late stage, the programmer might have moved on or forgotten all about the code in question. Also, it gets costly. An IBM study in the 1960s found that fixing a problem in the early stages of software development may cost a hypothetical dollar, but once it gets to the QA stage, the cost increases one hundred-fold, and once it reaches the consumer, a thousand-fold.

Worse, the engineering problems can sometimes be so fundamental or extensive they cannot be fixed with the best will in the world, and so it's back to the drawing board. The upshot? Company X may miss simultaneous release of multiple language versions (or elect to miss the core release date altogether).

Getting it right

To lay the blame for poorly engineered software at the door of the translator is obviously misguided.

Successful clients realise that localisation should be the single biggest concern of software companies. Even before the QA department passes a piece of software, it must consider its translatability.

Unfortunately, this approach is not taught at universities, perpetuating the industry bias against translation development as not being core to software applications. In keeping with this school of thought, programmers simply work on core programming, hand over the code to localisation engineers, and deal with the fallout, whereas a tightly managed parallel process of coding, translatability testing and translation is preferable, to attain time and cost efficiencies, quality and code integrity.

Translation can cause havoc with product releases.

Translation therefore becomes an exercise best handled by localisation service providers (LSPs) adept in software engineering, project management and automation. To make their task easier and take pressure off budgets, customers can use strategies to prepare their software for translation, condensing the rebuild cycle and hastening the whole development process.

Pre-translation
Run pseudo-translation

Pseudo-translation simulates the impact of translation on software. Many software companies build this into the development cycle, greatly improving the efficiency and success of software projects.

Good practice for LSPs is always to perform pseudo-translation with new clients. The extent of the problem they encounter may not be pleasing or fixable, but it will save a lot of effort and money if the software is found to be beyond repair. A translator without software testing or project skills is not likely to offer even that assurance.

During translation
Let the translator review

It is vital to allow the translator to see the translation in its context, to avoid mistakes based on misunderstanding - for example, 'home' can refer to a dwelling or homepage.

Post-translation
Develop one central test script

One test script (a set of instructions that will be performed on the translation to test that it doesn't compromise the functioning of the system), done in English, will expedite testing. Rubric uses this method to enable English project managers to work with translators. If a Hindi translator had to explain the problem, and developers had to struggle to find it on a Hindi page, that would be immensely inefficient. But if the script makes reference to test cases by number, it is universally identifiable. If the same test case comes up in different language translations, it is moreover a prima facie case for a problem in the source code, not a specific translation.

Ask the right questions

To find an LSP that follows the desired process-centric approach, whose business scales through use of automation (tools) and whose processes are guided by a strong project management competency to keep it all together, ask the following questions:

* What happens to get source files perfectly translated and back?
Pick holes in the process. If concerns crop up that the integrity of the software or quality of the translation may not be certain, then either the process or project management is deficient.

* What tools do they use?

* What software files are supported?

Only three or four formats are in widespread use. Thousands of file types are neither here nor there.

Only a select few possess these skills, and only they stand between the company and a failed software translation project, because they understand that translating software is very different from translating a product or brochure. It has a disproportionate impact on the software team that traditional language practitioners are simply not equipped for.

Share