What is software localization?

Software is the foundation of our modern tech-filled world. So many of the electronic devices we use every day are miniaturized versions of personal computers — devices capable of processing data, presenting the results, and sending the information anywhere. In a globalized world, software content and user interfaces need to be presented in local languages while also being mindful of cultural differences. This means that software must not only be translated, but fully localized. In our ever-expanding digital world, therefore, it is crucial to understand what software localization is.

Stretching the limits

Localization often focuses on content and visuals in a relatively static project, such as documentation. However, things are a bit more complicated when we look at the user interfaces of our machines. So, what software localization actually is can be defined by several limitations and requirements.

The most obvious of these limitations is screen size. Our monitors, mobile devices and television screens are basically boards full of pixels that are lit up using different colours. Needless to say, most content today is viewed on mobile devices with smaller screens, and the level of detail we can see is directly linked to the number of pixels that can fit in that screen. This is also why the devices we use daily produce such realistic images – screen resolution has increased over time. However, this increase in screen resolution has actually meant a decrease in font size – something that doesn’t always make people that wear glasses happy! Font becoming smaller while still readable ultimately means more text can be squeezed into our screens. And although this can help the software localization process, since translated text can be up to 30% longer than the original, font size can still only be reduced so much before it becomes unreadable, which is why any message generated by a system cannot grow infinitely.

To understand how software localization relates to screens, it’s crucial to recognise both the role and the constraints of your source content. That’s because the way your original, or source, text is written has a significant impact on how it can be phrased in your target languages. Using your original source text as a guide for creating text field size can backfire, as sentences can easily shrink or expand in size depending on your target language. And although software localization is a complex process that will detect potential issues like these, it’s only possible when your software’s initial design allows flexibility. Otherwise, the application interface will often use language and abbreviations that sound very artificial to the target reader. But please don’t blame the translators for this. They’re trying to wear a t-shirt several sizes too small, and the seams are bursting!

Program functionality

So, what is software localization aiming at when it comes to program functionality? The answer seems simple – keeping the original features intact, making them work in your target languages, and not introducing any bugs. Software data formats are designed to store and move the data around and are rarely in a human-readable form. The syntax is crucial; many unique characters and structures (tags, keywords, even indentations) are used to tell the software what the key is, and what the value is. This could be where a certain element should go on the screen, and any additional properties, like the labelling of a button, for example.

There are hundreds of programming languages, and each of them uses its own resource format. Luckily, the world has moved away from binary formats that cannot be easily read and converted. With text-based resource formats, the goal for software localization is clear – translate the text values, and then inject them into the same container to be used in the target language interface. However, functionalities are tricky. This piece of code is rarely linked to translatable resources. It’s a function that modifies some values, performs calculations and is usually hidden from the translators.

One of the most common traps is hardcoding forms that require specific values that may or may not exist in a particular market. For example, globally, we use different formats for street addresses, we have different tax systems, and even names and surnames can differ in structure and sequence. The main point to understand here is that values like these can be specific to a country or language. And that means that how we hardcode forms must be considered at the design stage of developing your software. Detecting functional errors at the translation stage likely means everything will have to go back to the development stage, affecting both your budget, and time to market.

Protecting the code

There are many ways to say hello, but software developers can’t resist welcoming the entire world. The technological enviroment has become ever more browser-based, and browsers just love HTML and Javascript. However, both languages include a lot of syntax and code that the end users should not see.

So, a lazy software developer might pay homage to the world by using a JavaScript command like this:

log('Hello,world! ');

The output would be generated into the so-called console, a browser equivalent of the command line we know from our desktops.

However, artistic souls who love the front end would probably write an HTML code like this:

<div class=" helloWorld">Hello, World!" </div>

…and then add colourful formatting and styling in the CSS representation of the helloWorld class.

Now, if we were to send those formats out for translation to someone who is not familiar with the constraints of HTML, CSS, or JavaScript, from the browser perspective, the result would be gibberish. It would almost certainly corrupt the way the page works because it would not generate the message to the console log. It may even affect how the page looks and display incorrectly translated pieces of the tags on our website. And again, that’s really not the fault of the translators – they shouldn’t see parts of unprotected code in their editors.

So, what can a good localization engineer do to prevent this from happening? Yes, you’ve guessed it – protect the code. Sophisticated editors used by translators, called CAT tools, have a neat feature called file format filters. Each format comes with a set of rules telling the program what part of the string should be extracted for translation, and what part should not be editable. This way, throughout the entire software localization process, the content always uses the same structure as the source file, while saving the translated strings in just the right location. That’s why we often describe software localization as injecting translated resources into source files.

Tailored for the globe

Of course, it’s nearly impossible for a product designer to have a meaningful understanding of all the many cultures across our globe. And that’s OK! We must just make sure we are aware of the limits of our cultural knowledge and exposure, and allow for these limitations. We should question if our product design allows some flexibility, especially in areas we may take for granted, such as how strings are generated and in which direction, their size and length, where they are located on the screen, the merging of two different strings, and so on.

Preparing your product for a global audience is called internationalization, and it involves more than 100 rules. Although most of the rules are technical in nature, the internationalization process also means thinking about the cultural assumptions we may make. Here are a few examples:

• Does your product use icons to represent an action? If so, could it be offensive to your target markets? For example, the finger and thumb ‘OK’ hand signal is considered quite rude in Brazil.
• Does the name of your product translate into something amusing in your target languages? For example, in Lithuania, Microsoft Vista is known by a slightly different name – Višta is the Lithuanian name for chicken!

Keeping your product free of potential geo-cultural issues is a big task, and, what’s more, it will always be an ongoing process. So, take expert advice, and learn from the mistakes of others so you can to keep improving your software localization processes. And to really excel at localization, plan for and incorporate cultural checks into your quality control process.

This article only scratches the surface of what software localization is. It’s a world full of challenges, discoveries, and continuous improvements. Here at 3di, we really enjoy these kinds of challenges. So why not take us with you on your software localization journey so we can help you to successfully grow your global business. Partnering with us will not only shorten the road, but also make for a much more comfortable ride.