Is your software localization something so far in the future that for now it doesn't matter that much to you? Change it. NOW is the right moment to start preparing for it.
Why is it so important to start thinking about your software localization from the very beginning of your product development?
It is because of the rules of internationalization that need to be taken into account as early as during the product development stage. This will make your localization process faster, which allows a faster product launch on local markets. It will also prevent you from redoing some parts in order to make room for translations.
Related content: 15 Myths About Software Localization
We at ATL know that some applications sent for translation are localization-ready and others are not. Both can be localized, of course, but in a different amount of time and with different effort on both ends: The translation company and the client.
Throughout the last 15 years of working with localization projects specializing in software translation, we have come across many scenarios. They all share a similar step, which is preparation for software localization.
This article explains how to prepare for software localization in order to easily launch the application on international markets. In short, here is some advice on how to prepare for software localization in order to avoid delays, overspending, and costly updates.
Internationalization means making sure that the software you create, is free from what is referred to as localization obstacles. Localization is mostly associated with translation, but it doesn’t apply only to texts. It is a broader term.
Localization obstacles are all sorts of issues that may delay the localization project and as a consequence, influence the software new-language-version release or update.
So, what needs to be taken into account while preparing for software localization?
Let's say that your software is written in two languages. One of them is English. It includes everything that the user will see on the screen. This can be buttons, error messages, options, descriptions, and more.
The other language is the programming language (code) which is used by developers to communicate with the device.
In short, the first one gets translated, the other doesn't. In order to translate it, the text for translation needs to be separated from the elements of the code.
In order to separate the elements that contain titles, error messages, option names, etc. from the parts not containing this information, use separate resource files. Move all the strings containing the elements that will be visible to the users, and that need translation, to the external resource files and give them special names.
The most commonly used formats for resource files are JSON, XML or YAML, but there may be others. When the translation is completed, you will have separate translated resource versions for each language.
Related content: 15 Languages for Translation That You Should Know About
When the translated content comes back, the resource files will be loaded by the library. The library identifies the correct string by using the language code but also the country code, which is also called locale.
When you specify the language but not the country, you may end up with quite a messy situation.
Related content: 6 Tips on Preparing Your Content for Translation
There are languages, like English for example, that are spoken in more than one country and that use different grammar rules (team are/team is), spelling (colours/colors) or even different terms for the same thing (metro/subway).
You will use one version of French for your software distributed in Canada and a another for France. Therefore, use the language and country code as follows: fr_CA and fr_FR.
There is a strong temptation to use placeholders and a fixed word order in sentences. But languages around the world use different word orders. Not only that! In many languages proper names look differently when used in a different context.
Name: Joanna - Imię: Joanna
Hello Joanna! - Witaj Joanno!
It is therefore better to create strings that are complete sentences. In the ideal scenario, the placeholder can be moved around and the word order can be controlled by the translator to make it more natural sounding in the translated language.
In order for the product to be ready for localization you will need around 50% of extra space for text expansion. Leave this space for expanding or contracting the text. If you don’t prepare for this, your strings might overlap with other controls.
There are languages that are much longer than English, like German or Finnish, but there are also languages that use fewer characters for the same information, like for example, Japanese.
Naturally in all languages there are synonyms that linguists can choose from. It is also used in practice to shorten translated strings.
But this solution leads to certain consequences. Choosing shorter but less commonly used synonyms can make your product information sound unnatural. An extreme text shortening can make the messages incomprehensible and the interface will require editing after translation.
Related content: 5 Ways That Translation Revisors Affect Your Business Growth
Very often, companies use symbols instead of inserting text for buttons or options. This is often the case for mobile apps or anywhere where there is limited space for text display. This is the Graphic User Interface (GUI) and it also needs localization.
Before introducing a new symbol into your App, make sure it is not offensive in any of the countries where you intend to sell. The well-known thumbs up is as rude in some places, like Sardinia and parts of West Africa, as the middle finger is in the USA.
For globalization reasons, it’s better to use symbols instead of text, which may translate into a much longer content.
If you want to include text on graphics, think twice. Images without a text do not need translation unless they are symbols that need to be localized. If your graphics contain text, separate the text to allow its translation.
In order to be compatible with your clients' ways of displaying time and date you should think about that in advance. Refrain from hard-coding numbers, units, dates, and times. They need to be localized. You can use standard ISO format or let your translation professionals decide what is the best solution for their locale.
Related content: A Guide to an Efficient UI Software Localization Process
If your software isn't flexible with regard to that, it may lead to real consequences. 03-05-2020 can be read as May the 3rd or March the 5th. That makes a bit of a difference, doesn't it?
Use a library with localized files to provide your users with correct units, dates, currencies, etc.
You already know that the length of words differs for various languages. There is one more thing that needs to be considered as early as during the development stage. There are special characters (e.g.: German, Spanish, Polish), double-byte characters (e.g.: Japanese, Chinese, Korean) or RTL (right-to-left) languages (e.g.: Urdu, Hebrew, Arabic).
Use encoding that supports special characters used in languages like French or Spanish. Use data type that can handle Unicode. UTF-8 is best for most languages. Neglecting that may lead to conflict between the coding of a character and the way it is decoded.
Most of the workload associated with translating key terms is on the localization service provider's side, but there is also a bit of effort needed from you.
First of all, you need to ask your localization service provider for terminology creation, or agree on terminology creation when the localization team suggest it as an additional step.
Related content: 15 Myths About Style Guides and Glossary for Translation
You may also be asked to suggest terms or approve the suggested translations. Naturally, you don't have to learn several languages. Your role is to cooperate with the localization experts and either assist them with choosing the best translation or simply connect them with your local distributors or testers that may be of assistance.
Your translation company may also ask you how you want to address the users. It is important to work on key terms in order to avoid misunderstandings. There are already existing translations that are familiar to software users on local markets.
For example, terms like save or enter are commonly used for all sorts of products and it would be advisable to follow common translations in order to avoid confusing the users.
In most cases there is no need to reinvent the wheel. If the commands are the same, you may choose the already-existing translations and save money. There are public Microsoft UI glossaries, so you can start from there.
Related content: How to Really Save on Translation and Localization
The quality of the final product is based on the amount of time allotted to preparations. That brings us to reference material, which is crucial for localization process.
In order for the localization team to not have to guess how the software functions, make sure to provide as much context as possible. It’s good to have documentation ready or provide as many references as possible. All available context should be provided together with the translatable strings.
Preparing descriptions, especially of single word terms, may save you time after translation implementation. The term Select can be used as a button or elsewhere in your application. Including the information about the place where the text will be displayed helps translators to choose the best translation.
Related content: How to Reduce the Turnaround Time for Content Translation
For buttons it would be best to use words with a similar number of characters as the number of characters in the original English term.
For the sake of providing the most accurate translations that will boost your product's success on the local market, you need to work on providing as much context as possible to the translators, or answer their queries. This is especially the case with very innovative solutions.
Pseudo-translation is the process of taking the source text and generating a fake translation using a set of random characters, including special characters for that language.
The pseudo-translated text looks like rubbish, but there is a good reason to use this step while preparing for an actual software localization project.
It allows you to spot potential problems with the display of your translated software before even starting the translation process. You can find hard-coded elements or possible issues with encoding.
Pseudo translation generates character sets that are commonly found in the language, so you can not only see if the special characters are correctly decoded, but also if they look right from the user's perspective.
It also takes into account the average difference in text length, so it adds an additional 20-45% for languages longer than English. This can predict any possible issues with text expansion or contraction.
The process allows you to verify how the text displays for right-to-left readers. It may seem like an additional effort that takes time, but this is an investment in the future of your software and its global availability.
It saves you from stressful, last-minute changes to source code. Testing the application before translation and implementing required changes limits the number of tests and fixes after the translation process. This eliminates the overlap work of different language specialists testing the localized application.
Related content: How to Measure the Quality of Translation
You also save yourself the time needed to update files in all the target languages for any left-over hard-coded messages.
Properly localized software generates increased user satisfaction with products that can be understood at a glance. It also reduces the number of troubleshooting issues.
Software localization takes effort, and if anybody tell you that it’s easy, that person is wrong. It’s of paramount importance to be prepared and disciplined when setting things up from the start.
Hard-coding is easy. Thinking about the here and now is easy. But easy doesn’t pay. If your goal is to have an international product one day and introduce it to global markets, make sure to clearly communicate this vision to your development teams.
Programmers make strategic decisions when adding elements of code. Make sure that these decisions are in line with your organization’s direction of development.
Internationalization is a set of good practices that an organization applies to a software product in order to avoid last-minute, time-consuming changes to the code.
If you want to test your software for localization obstacles and get a quote for translation, contact us.