First-time localization and how to get it right

Is your product internationally ready?
How should you have it translated?
What do you want the translation vendor to do?
What information does my translation vendor require?
Summary

Breaking into international markets is a daunting task for companies. It can be an expensive part of your budget to do it for the first time, so it’s important to get it right. Localization is more than just translating the words. Asking the right questions at the start ensures you deliver a successful and profitable first-time localization project.

1. Is your product internationally ready?

Before you begin translation of your products interface, text and files you need to ensure that the product is ‘Internationally Ready’.

There are two elements to this: internationally enabled and internationally aware.

Internationally Enabled

If a user took your product today and installed it on a French, German of Japanese system, would it still work in English? Even though your product may be developed in English it should
be designed to run on the same operating system in different languages. For example, many network administrator tools are only in English but run on operating systems in every language as English is the common language of many network administrators around the globe.

When talking to your translation vendor you will often be asked if your product is DBCS enabled or Unicode enabled. This essentially asks if your product is designed to handle multiple character sets and is enabled to work on multiple languages operating systems. Your product must be enabled before you can localize it.

Internationally Aware

Translation is more than just words. Around the world there are many local differences; the US uses dollars and Europe uses Euro. Some countries use commas for thousand separators others use the period. There are many elements for which to test your product.

Local testing issues
National conventions
Date format support
Time format support
Numeric formats
Currency formats
List separators
Telephone numbers
Address formats
Proper names and titles
Measurement systems
Page formats
Conventions for capitalization, uppercase and lowercase
Comparing and sorting
Paper size, envelope format and addresses

When it comes to the international testing of your product all of the above local issues need to be covered. You should also check sample file names and contents for local issues. It’s a common error to have data in your sample files that causes internal problems. There is a tendency for example to use flags in software to signify country information. This can be politically sensitive in some countries as is not normally recommended.

Your product should be able to read such items from the operating system instead of assuming defaults value. If you correctly handle the various international elements you are said to be internationally aware.

Watch out for common coding errors

One of the most common faults that prevents product being translated is the hard-coded string. In order to translate a product the translation teams must be able to access your text, dialogs and strings in order to replace them with the target language equivalent.

It is a very common error for software developers to place text inside code such as HelloString = “Hello” + “What is your” + “name”;

Embedding strings in code like this makes it very difficult to translate them.

Top 10 tips for Software Developers

1. Use Multibyte Functions: Always use multibyte formats of code functions. Check your developer API for more details.
2. Third-party Tools: Test all third-party tools: APIs, add-ons and plug-ins and make sure they are internationally enabled.
3. UI Separation: Keep your UI separate from the code. Don’t hard-code strings. If you do, the translators can see them.
4. Concatenation: Don’t concatenate strings as language structure changes from language to language. Your code may have be reengineered later.
5. Chars: Do not use ‘Chars’ for string parsing, unicode characters are multi-byte.
6. Expansion: Leave at least 20% expansion room on all dialogs. Most languages are longer that English.
7. No Assumptions: Never assume default values. The name for the default page format in the US is letter. In Europe it’s labelled A4.
8. Mock Translation aka Pseudo Translation: Mock translate to ensure everything works before translation begins.
9. Input Methods: Ensure all character entry methods are IME compliant for Asian languages.
10. Local Testing: Check your code handles all local issues, see local testing issues

2. How should you have it translated?

There are two schools of thought on how best to translate: binary translation or source file translation.

Binary Translation

If your product is correctly enabled and has followed all the guidelines for separating text from code then this is the ideal method.

You product is compiled as normal. This creates the various running executables DLLs, EXE etc for your product. However as the UI elements are separated from code translation tools can extract, translate and replace text in the binary files. The main advantage of this system is the speed of translation as it does not interrupt your development process. This disadvantage of this system is that you have to track all of the DLLs and program files in your products source control system.

As the translation teams do not touch any code it greatly reduces your exposure to errors. Therefore you do not have to compile your code; testing time is greatly reduced, saving you money
and getting your international product to market faster.

Source File Translation

This is the traditional approach where your source files are sent to the vendor for translation. Translation tools parse your source text and identify the strings for translation. The advantage of this system is that the files transferred can be small. You simply send the files to the translation vendor who returns them. When returned the files are simply dropped back into
the source control system and recompiled. The disadvantage is that it is error prone and errors are usually only found at compile time which is an expensive area of development to fix errors. It also means that you need to test your product more as each language build is essentially a new product.

Why is this important?

There are a variety of different software tools and you need to be aware which ones best fit the method of translation for you, and which ones your translation vendor is strongest with. Each translation vendor has particular strengths: some are better at binary translation, others are better at source file translation. So you need the right system for you and the right system for your vendor in order to be successful.

3. What do you want the translation vendor to do?

This may seem like a simple question but is an important one to ask. There are two options to answering this question.

translate the files only
deliver a working translated product

Translate the files only

For most companies they prefer to just have the vendor translate the files and return them. These files are then incorporated back into the product development them where the language versions are compiled and foreign language versions build. They are then tested internally or outsourced to a vendor to test.

Deliver a working translated product

The alternative method is to have the vendor fully Localize the product. The translation vendor completely translates, builds and tests the full foreign language product. You then receive back a full working version of your product in the new language. This is often referred to as ‘gold master’ delivery.

4. What information does my translation vendor require?

Is your product enabled?

Most translation companies offer internationalisation (i18N) services. So this is one of the first questions you will be asked. What is important to the vendor if to simply the translation process and eliminate all potential international errors for you before you start.

What file format is your product developed in?

There are a variety of different software tools and you need to be aware which ones best fit your process. Most vendors work with a wide variety of translation tools. Some file formats also require special skills to translate them. So the translation vendor needs to understand what tools are best for your product and what people resources are required to deliver the best product for you.

How many files are in your product? And what is the word count?

Typically translation projects are priced on a word basis for translation and a file basis for engineering work. Having this information enables the vendor to accurately price your translation project for you. You should be aware that prices vary from language to language and vendor to vendor, depending on how their systems and tools work. The more you understand what system best fits your process the easier it is to understand, which is best for you. Cheapest is not always the best.

Before you engage with a vendor you should have the following information to hand.

Internationally enabled: List what languages your product has been enabled and tested for.
Internationally aware: List what international testing your English product has undergone.

File formats used in product

List all file format types here.

Number of files: List the number of files for each type.
Word count: You should be able to identify the types and volumes of words for each file format.

How are we translating?

Source of Binary Method? What are we asking the vendor to do? Translate or deliver gold master?

5. Summary

In summary, the key items to ensure your successful translation project are:

ensure your product is internationally enabled.
decide if translating binary or source files.
decide what exactly you need the translation vendor to deliver.
reaching out to new markets is a very exciting process for any company, especially markets that do not speak your language. It can also be a daunting task when you are new to the translation process. However with careful planning and preparation the process can be done smoothly ensuring it is a successful and profitable venture.

This document has been compiled by Damian Scattergood, managing director of STAR Translation. Damian has over 20 years of experience in the localization and translation business. He has worked both on the producer side and vendor side of the business. He regularly contributes to industry publications on translation and localization topics and is recognised as an authority in the field of localization.

Advert