Subscribe

Cracking the code

The secret to code that travels well - break it.

Ian Henderson
By Ian Henderson, chairman and CTO, is co-founder of Rubric.
Johannesburg, 29 Apr 2015


I've said many times how important it is to write software with localisation in mind.

Is it online? Then it needs to be translatable. Is it an e-commerce site? Then payment should be provided for in different currencies. Does the company want locals to buy into it as an authentic local experience in their country? Then time, date and number display formats right must be correct.

Many, if not most, of my clients do not realise this at the outset of a software project, and once they do, the application, Web site, set-top box, video game or app is so far along in its development cycle that to translate it would endanger the project. In short, it would 'break' the software, which at this late stage may or may not be fixable, forcing the client either to go to market with an unsuitable product, or to call the whole thing off and start from scratch.

To avoid having to make this terrible choice, code should be run through pseudo-translation (PT) - a software-based process that simulates how the software will display once translated. Quite often, it will break the code in various ways (see below), giving the company an opportunity to pre-empt and fix deficient code before breakage actually occurs.

Worst-case scenarios

When running a piece of code through PT, some errors will stand out like a sore thumb, while others will be obvious only to a translator.

* Number formats in the code will be interpreted wrongly by local users, throwing out currency amounts by orders of magnitude, causing confusion with dates or displaying time in formats readers will find difficult to cope with;
* The usual payment processor may only be set up for payments in the domestic market, not international territories;
* The calendar widget might only be available in English;
* The Web site may be graphic-intensive, with overlaid text, and the original source files may be missing, forcing the company to redraw the graphics at a high cost;
* Sometimes a single apostrophe (commonly used in Italian or French, eg, hors d'oeuvre) breaks the code, because it is interpreted by the Java development language as delimiting text; and
* Whole chunks of text will remain un-translated (due to the client thinking it won't affect the user interface and hard-coding it; or preferring to hide all code containing intellectual property; or because they forgot about a third party widget provider's contribution to the software).

The magic

How does PT do its magic? A process has been developed that manipulates software strings in various ways to simulate the facts or effects of translation. Such manipulation includes pre-pending, appending or inserting characters, or lengthening a string.

Adding characters can help detect when a string is completely impervious to being translated (for example, because the software is hard-coded). It will be obvious because the characters won't show up in the dummy translation. Some insertions, such as hyphens, will break the code, and must therefore be used as a tell-tale sign of deficient code.

It is also good practice to include Asian characters in the mix, because of the way they are displayed in some font types. In times gone by, Arial, a popular choice, displayed Chinese characters as blocks. If the developer didn't know that or didn't consider Chinese markets, PT is a good reminder that Arial Unicode is a better choice than Arial in such cases.

Pseudo-translation won't fix any problems directly, but using it early on will allow a company to fix them cost-effectively.

PT insertions may also include concatenated words. Blue pen is translated as "Un stylo bleu". A blue mouse is translated as "Une souris bleue". If it is discovered that the phrase is made up of two parts, the developers can be alerted to the issue early on.

Other tactics include lengthening a string to test for areas in the software where there isn't enough room for translation. A longer string will be truncated if space is an issue.

Then there are generic characters such as date and time formats, to see if they're properly converted for the region in question.

Catch it quick

PT won't fix any problems directly, but using it early on will allow a company to fix them cost-effectively. The sooner the developer can 'break' the software in a safe, simulated scenario, the cheaper (and more feasible) it will be to fix the localisation deficiencies.

The issue is far from trivial. A mobile network launched lower-end smartphones featuring a new operating system, translated into two languages, on 2 April. Had they waited until 29 March to test issues, they'd have had just half a week to fix what might have been serious issues. Instead, they uncovered several issues long before that, taking considerable potential pressure off developers.

Unfortunately, a PT competency is light years beyond a pure translator's skills. Most translation companies simply translate the text they are given, leaving the client to deal with the fall-out when the localisation fails at the eleventh hour.

The correct way to go about it is to engage a true localisation service provider that can demonstrate the software's integrity after translation.

Share