An Introduction to Software Translation

By Susana Domínguez, Project Manager at Nóvalo.

Computer software, or simply software, also known as computer programs, is the non-tangible component of computers. Computer software contrasts with computer hardware, which is the physical component of computers.

When we speak about “software localization” we refer to the process of translating and adapting computer programs to the linguistic, cultural and technical requirements of a target country. A complete software localization project normally includes the following components: the own software, online help and software documentation.

However, in this post I will focus specifically on software translation itself as this should be the first step in a complete software localization project.

In general, software translation means the translation of all graphical user interface components of a software application, such as dialog boxes, menus, error or status messages displayed on the screen.

There are two methods when dealing with software translation: working with non-compiled resource files (original files written in the programming language) or working directly with the compiled program files (binary files). In first case, you could use a text editor, a resource editor or a CAT tool and regarding to the second method you could use a resource editor or a software localization tool.

Let’s see the advantages and disadvantage of using each of the methods:

Resource files 

-No need to use a special editor-Difficult to keep an overall view
-No need to use expensive software localization tools-Impossible to see the translated user interface appearance
-After translation, files must be compiled and linked to create a high quality application-Risk of translators altering the software code
-Difficulty rebuilding original file context information


Binary files

-WYSIWYG option in the software localization tools-Special editors or tools required 
-Context information in binary files
-Avoids accidental changes in the source code
-Easy to resize options instead of using abbreviations


Please see some sample screenshots below:




Thus, it seems easier and more efficient to translate using binary files. Unfortunately this is not the most common method, specially if the software is a beta version or a non-final version.

When working with resource files, translatable text is usually embedded in coding and normally placed between quotation marks. Most CAT tools include standard filters to process translatable text. However, it is important to know the following information:

-Translatable text strings are placed in quotation marks. Thus, you must avoid using quotation marks within strings. If it is absolutely necessary you can use double quotation marks.

Example: “Click “”OK”” to continue”

-Do not add/remove leading or trailing quotation marks.

-Do not add/remove leading or trailing spaces in strings.

-Do not use & symbol in translations as this symbol is used to identify the hot keys. If it is absolutely necessary you can use a duplicated symbol (&&).

-If there are strings defining date, time or number formats such as mm/dd/yyyy hh:mm AM/PM (displayed for example as 01/24/2014 10.00 PM) and they must be changed in target language, you must first consult the software publisher. These codes often remain untranslated as the software application retrieves this information from the operating system.

-Never translate file names or file extensions.

-Follow the comment lines added by the developer (they can include useful context information, specify character restrictions or untranslatable strings, etc.).

-Follow the control codes such as \n (line break); \r (carriage return) or \t (tab).

Irrespective of which method you use for software translation, localizable components are all data displayed in the user interface. We can differentiate the following:

Dialog boxes: windows or screens used to change options or settings. They can include tabs, fields, check boxes, lists, etc.

Menus: drop-down lists used to select commands and options, or to access dialog boxes. They include menu bars, menu options and context menus.

Strings: error messages, status messages, questions and tooltips used in the application.

This part is usually the most difficult one as strings do not contain context information. Furthermore, variables and placeholders are very common in this part. They will be replaced with a value, word or string by the application at run-time. In this way, it’s very important to understand these elements and place them in the right position during translation. Some examples are:

VariableReplaced value
%sAlphanumeric string
%dDecimal integer
%pPage number
%uUnicode character
%ldLong decimal integer
%xHexadecimal integer
%gFloating-point number


Sometimes variable comprehension is easy (“The document %s has %d words”) and sometimes it’s difficult (“%s to %s”).

We also found the gender problem when we translate from English to Spanish for example.

Hot keys: hot keys are key combinations that allow you to access menu or submenu options. They are displayed by one underlined letter (for example, Open) in the application and by a & symbol before the letter (for example, &Open) in software files. By pressing this key in combination with the Alt key, you can activate a certain command. A hot key assignment must be unique in each menu, submenu or dialog box to allow correct software functionality. The use of some letters is also preferred (use the first character or a character as close to the beginning of a word as possible, don’t use accented characters or avoid using characters with downstrokes, etc.). It is important to be consistent with the hot keys used in the target operating system.

Shortcut keys: they are also keyboard combinations that allow you to access menu or submenu options. You can activate a lot of commands by pressing the Ctrl key in combination with a function key or letter. You must not localize combinations of the Ctrl key with a function key (such as Ctrl+F12). You can localize combinations of the Ctrl key with a letter, number or symbol; however this is not recommended as they are often common to other applications. You must also take into account that many key names on the keyboard are localized in many European languages and that a shortcut key can only be used once in an application.

Graphic elements: they can be bitmaps, icons or cursors for example. In Microsoft Word we can find bold, italic and underline icons localized in Spanish version.


 In addition we can establish some general guidelines when translating software:

-Creativity: avoid literal translations, try to understand the function of each option.

-Be consistent with terminology, style and grammar used in all software components.

-Use consistent terminology with target operating system when software makes reference to it.

-Use consistent translations between menus or options and related dialog boxes.

-Avoid using the first person (I or we) in messages.

-Try to use the imperative mood to make the text easier to read.

-Adjust capitalization to your target language standards.

-Adapt user interface language to meet local conventions.

There are of course a great number of software translation guidelines but we can get more detailed information in different software localization style guides. Style guides include topics as the way to address the user, syntax, pronouns, verbs, punctuation, capitalization, acronyms, terminology, trademarks, character restrictions, etc.

If you would like to obtain further information, please refer to Microsoft complete style guides in different languages. You can download them from this web site.

Finally, I would like to highlight the main problems we face when translating software:

-Lack of context

-Variable meaning and where to place them within translation

-Length restrictions-Gender and number problem when translating from English to other languages

-Use of a noun or infinitive to translate some options. For example, “Search” could be an option or menu (and we could translate it with the infinitive “Buscar” in Spanish) or it could be a dialog box name (translated as a noun, “Búsqueda”).

-Use of an infinitive or imperative to translate certain confusing strings that can be interpreted as a user instruction, an option, a tooltip, etc.

-Detect untranslatable elements such as capitalized words (MODIFY), underscored words (file_format) or apocopated words (DevUnit).

Therefore, it is clear that queries are an essential part in software localization.

I hope you have understood with this post what software translation is and the involved components. This topic is very wide but I have tried to clear some of the main concepts.

However, if you are curious about this, I recommend you the book “A Practical Guide to Localization” by Bert Esselink, which I have used to write this post.

See you!