Lost In Localization

Getting the message across

Ever since Sophia Coppola’s film release, the concept of “Lost In Translation” is a pretty familiar one, even outside the translation industry, while the notion of “translation” is generally regarded as the process to convert words from one language into another, but words are not the only way to convey messages.

Most of us, and notably those reading this piece of writing, are used to tablets, smartphones, and computer Graphical User Interfaces (GUI) featuring purposeful smallish, rather sketchy, images known as icons.

Making the most of the popular “An Image Is Worth A Thousand Words” saying, such icons are used to conveniently put messages across. Save for some exceptions, those icons can also be expressed in words like File, Cut, Back, or Search — Therefore, it stands to reason the same caveat regarding the loss of meaning in translations applies to these message-bearing icons.

Enter localization

The process to adapt information technology (IT) products from one language, culture, or region to another is known as localization. IT products range from software applications to websites, from eLearning courses to appliance displays, and anything in between.

Such localization process not only involves the translation (if so required) of any text rendered on screen or audio played, but also the necessary user interface layout tweaks to accommodate the newly translated text and the appropriate rendering of the different formats customary to the intended target language for dates, currencies, ordinals, and other values stemming from the operating system, as well as any other GUI element presented to the user. The aforementioned icons are found among those GUI elements subject to be localized… but they rarely are.

Many applications and websites include a house icon conveying the meaning of “Home” as the start or root to navigate throughout them and as an anchor available to the users for them to get back, well, home. However, coupling this concept to the word “home” is only valid in English. Tapping or clicking on the house icon brings up the home screen or page but they are not known as such in other languages. The terms generally used to translate the word “home” are more related to “Main”, “Root”, “Reception”, etc. – None of them having anything to do with the house depicted in the related icon.

Developers and graphic artists can get creative when designing the images to be used as icons on button faces or navigation links, to name a couple, but these images need to be related to the results produced when clicking or tapping on them. Such relationship between an icon and what they stand for or the action triggered by them is usually established in grammatical terms: Paper sheet/File, Scissors/Cut, Left-pointing arrow/Back, Magnifying glass/Search.

This grammatical relationship between images and their meaning should also be applicable to user interface elements meant for users speaking languages other than the one used to establish such image/meaning relationship at design time and, therefore, the same translation risks lurk over these interface elements than in any plain text translation.

More examples

In English, the act of sleeping is also referred to as “to make zees” and conventionally it has been represented by “z” characters in American cartoons since the early 20^th century. On the other hand, when an alarm goes off it is possible to mute it for a while before it goes off again, giving us the chance to take a snooze. Therefore, the correlation between a zees icon and snoozing an alarm is immediate… for English speakers. Even if the idea of zees meaning sleep is known in other cultures, the action of snoozing an alarm is referred to as pause, repeat, or postpone an alarm in other languages: What has “sleep” to do with postponing an alarm?

Some email applications use icons depicting a curbside mailbox with a flag or carrier signal raised to indicate that the mailbox it represents contains unread messages. Whether the flag is up or down is meaningful to US users, because they are used to having their outgoing mail picked up from their own mailboxes, something signaled to the postal carrier by raising their mailbox flag. Goes without saying that for most users in the rest of the world this flag feature in a mailing icon is meaningless and goes mostly unnoticed, so it could just as well have a daisy instead of a flag.

While testing localized versions for a major software company, I logged a defect (or “bug” in software parlance) for version 6 of a globally known application suite which hadn’t been pointed out in any of the five previous releases. Let’s try to imagine the software application we’re using includes a button with an image depicting a character “5” above a character “H” and a down-pointing arrow next to them. In best case scenario, I guess each one of us could come up with our unique interpretation, but few would infer such made-up icon means “ascending sort”. Well, for those who speak languages with alphabets that don’t start by A or don’t end by Z, the commonly used A-to-Z icon signifying ascending sort is as puzzling as our imaginary 5-to-H icon – Let alone those non-Latin script languages. From then on, the said application suite includes properly customized sorting icons for each target language.

In software, it is common practice to compress files and folders into smaller files so they can be stored and moved around more conveniently. One of the most popular standards to carry out this compressing job uses the .zip extension for the resulting filename and “to zip a file” is the process to compress it. Therefore, when an English-speaking user sees such compressed files represented by a zip fastener, the relationship between the two is immediate. If that user sees a banana icon instead, it would be much harder to relate such icon to any zipped file. Well, the banana is to an English speaker what the zipper is to a non-English speaker.

Lastly, a compact disk in flames is easily related to “CD burning” in English but, in other languages, its interpretation would be closer to “set a CD on fire”—That is, no relationship between the appearance of the icon and what it actually does or represents.

If the localization principle is that the resulting product has to look and feel as if it has been developed in the intended target language, these flaws prevent accomplishing such goal.

I’m inclined to believe each language has its own glitches when it comes to interpreting odd icons but the ones above should somehow suffice to illustrate the issue. The question then is why these localization flaws make it to the localized releases.

The software development cycle

As it is perfectly understandable, programmers develop applications in their own language or, rather, that of their employer or of their target market. When it comes to develop an application or create a website, English is the perfect candidate:

· The largest software powerhouses are based in the US

· It’s spoken in some of the wealthiest markets, and

· It’s nowadays de facto global lingua franca

These, amongst others, are pretty compelling reasons supporting the fact most commercial applications are developed with English-speaking users in mind.

The developers cannot cater for each of the languages the application will potentially be localized into, which per se is a sound reason for focusing on a particular language when developing an application. But this doesn’t mean that GUI elements designed for that specific language have to remain that way.

An application properly designed and engineered for localization provides a means for its GUI elements to be adapted to other languages as required. In programming, these elements are known as “resources” and they are included in separate files or resource files. This type of files can be edited independently, so the application source code doesn’t need to be available when localizing an application.

Possible causes

A well-crafted application should undergo a thorough testing process and its localized counterparts are no exception. However, often times the localization testing is improperly designed for the purpose. By and large, the linguists in charge of translating texts for the localized versions are limited to handling the texts out of context, isolated from the running application or website. Texts and their associated graphics are only displayed side by side at run-time, which is when these non-written linguistic and cultural issues could be spotted. Instead, the run-time or functional testing is done by technical teams which don’t necessarily speak the language of the application being tested.

Furthermore, testing is the software development cycle’s Cinderella and localization testing is Cinderella’s Cinderella, if you get my drift. When cutting budgetary corners, testing is the immediate area to apply those cuts.

Savings in testing can be accomplished by simply cutting them short or by automating them. Automated testing can be designed to check whether icon X performs as set out in the specifications, but it cannot assess whether a potential user might have a hard time figuring out what the icon’s outcome is, thus hampering the usability of the localized application or website.

In any case, perhaps the most convenient way to avoid these potential drawbacks in localized outputs is a thought-out specifications process and have the forth-coming localization process in mind since inception but the decision to localize IT products is quite often an afterthought.

Makeshift workaround

Users learn to use and get familiar to just about any icon, as proven by the cryptic and rather abstract circle, square, triangle, and cross icons found in mobile devices and gaming consoles, or by the vertical ellipses and “hamburger” icons found in applications and web interfaces.

However, even if users get to learn and use the most meaningless and drab of GUI components, operating them this way is just a workaround, far from the intuitive interaction it is supposed to be. Sometimes even an image isn’t worth a thousand words and fails to communicate the intended meaning.

The process to get familiar with application and website interfaces riddled with counter-intuitive hints takes longer and thus, the resulting user experience is less rewarding when compared to a properly localized interface.