6 Considerations When Preparing for Software Translation

Software translation and localization can be highly complex because of the challenges involved seeing program text strings in context. Many of our previous blogs have touched on software and website localization. Ideally, a software application should be internationalized before either translation or localization takes place. Our previous blog, Why Internationalize Your Code Base, covers the main concepts in that arena.

This blog focuses on just six of several dozen considerations to be made when preparing your application for software translation. To simplify things in this blog, we will assume that your application is for Windows and uses standard windows programming tools and environments.

Preparing for software translation

In an ideal world, you would be able to thoroughly complete and test your English software version before translation begins. Although this would eliminate many problems, this is seldom the case; most companies have to begin translation before code is finalized in order to meet concurrent release of software in multiple languages. Your English version should have all strings in resources, and all date/time values should be formatted using system settings. This will help to eliminate bugs that might appear when moving strings into resources.

(1) Working with string resources

One of the main reasons for using string resources is to simplify software translation. You should definitely make use of the string resource table. All strings displayed to the user, including formatting strings, should be retrieved from the resource string table. This will reduce the time required by your translation company to perform necessary translation tests before target language software versions are tested.

Here are some other tips for handling strings in preparation for software translation and software localization:

1. Strive to use consistent error messages. For example, the following error messages all say essentially the same thing in principle, but could all have identical wording to be more efficient:
   “Selected File failed to open.”
   “Failed to open file.”
   “File could not be opened.”
   Even if you have to slightly generalize an error message, it may be worth it to streamline translation. Some English software applications have vague or cryptic error messages, which could be improved for English-speaking audiences, let alone global users who will be using a translated version.
2. Minimize the number of %d and %s formatting items in each string. A string with two %s strings could require the strings to be displayed in reverse order when translated. Of course, this is very difficult to handle within the code. Eliminating or minimizing the number of complex strings reduces your chances for difficult translation challenges like the one described above.
3. Strive to write strings that make sense on their own. The linguists at your translation agency won’t always understand the context in which each string is used. Short or vague strings will certainly generate a call from your translation company asking for clarification about what the string is intended to “say.”

(2) Dialog Sizes

English translated to another language will increase or expand character count more than 50%. Extra space for text expansion should be allowed for your dialog boxes. Although you can resize your dialogs before after software translation before rebuilding the translated application, the process will be much more efficient if most of the dialogs and controls have sufficient size before translation.

Element Resizing

Extend text frames as far as possible to allow text to grow when it is translated. When possible, it is best to put text labels above UI controls such as edit boxes. This positioning allows for the greatest extension of the text field, as shown in the screen capture below.

For each localized dialog box, test to make sure that the order that the user activates dialog elements via the Tab key still makes sense. If the tabbing order isn’t consistent, someone on your translation company’s software localization team probably changed the relative position of dialog elements to get the translations fit, or the localizer might have set the coordinates of an item outside the coordinates of the dialog box itself.

(3) Grammatical issues with target languages

Even clear, consistent software strings can pose challenges during the software translation process. Seemingly simple words or strings can require difficult translation decisions due to context-sensitive choices in the target language regarding gender and verbs vs. nouns.

(4) Noun gender in target languages

We are somewhat spoiled when programming in English, since there is no gender for nouns. One noun works in an all-purpose fashion in all contexts. As an example, nearly every software application has a “New” command on the File menu. A new what? It would usually indicate a “new file.” It doesn’t matter what the new item is in English; there is only one version of the word new. But in the Spanish language, it would have to be Nuevo or Nueva. In this target language, the gender of “New” depends on the gender of the “what” or object selected: if the “what” is masculine, you need Nuevo; if the “what” is feminine, you need Nueva. Your translation company linguists will need to understand what the new item is so that the correct gender is used.

(5) Is it a command or a description?

In English, there are cases where a phrase might be a command or a description. For instance, your English-language software may have a phrase such as “Open this File”. This could be a command, telling the user what action to take. It could also be a description of a menu task, like the messages which appear in the status bar when you highlight a recently opened file in the menu. The phrase is the same for both the command and the description in English, but this may not be true for all target languages.

There are many solutions in windows programming. Here is just one of many potential solutions; instead of prefixing all string identifiers with IDS_, you can implement command identifiers with IDSC_ and description identifiers with IDSD_ as shown below:

#define IDSC_OPEN_TEXT_FILE “Open Text File // this is a command

#define IDSD_OPEN_TEXT_FILE “Open Text File // this is a description

The identifiers in the code example above and the descriptive text at the end of each string makes it very obvious which string is a command and which string is a description.

(6) With this naming scheme, is that a noun or a verb?

Many nouns and verbs are the exact same word in English. For example, the verb “to call” will appear as “Call” on a menu item or button. In this case, it is used as a verb. But “Call” can also a noun. In English, they are the same. However, in many Latin-based languages, the noun and verb are different. Your translation agency linguistic team will always have to know the context in which each term is used. A potential solution to this problem is to use different string identifier prefixes for nouns or verbs as described above for commands and descriptions.