An Introduction to Software Translation

4 June, 2014Susana DomínguezNo CommentsBlog, Translating and Editing

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

Binary files
Advantages Disadvantages
-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:

Variable Replaced value

%s Alphanumeric string
%d Decimal integer
%p Page number
%u Unicode character
%ld Long decimal integer
%x Hexadecimal integer
%g Floating-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!