Software Localization

Translate with Across


Today, there is virtually no area in our private and professional sphere in which no software is used. On conventional PCs, software can be found in the form of an operating system on the basis of which application software is installed—from office applications to multimedia applications to video games. Software can also be found on omnipresent mobile devices, such as smartphones and tablets, and on the Internet in the form of web applications. Additionally, many other devices and machines also contain software: household appliances, cars, industrial production systems, etc.

To increase the user-friendliness and the user experience, such software is often needed in various languages apart from the language in which it had originally been developed. This is where software localization comes in, a subject area that is becoming increasingly important.

Translation = Localization = Translation?

When talking about software (and web pages), the translation process is often referred to as localization. Localization is usually defined as the technical, linguistic, and cultural adaptation of a product—in this case of software—to a regional market. Thus, localization comprises more than the mere translation.

By the way: The term "localization" is often abbreviated as L10N, consisting of the first and last letters of the word and the 10 letters in between.

Scope of the Software Localization

The localization of software comprises the translation of the program files that make up the software as well as the localization of other software-related components, such as the online help, the production documentation, the associated web pages, etc.

This description, however, focuses exclusively on the localization of the actual software.

The software content that needs to be localized mainly comprises texts that are displayed in the user interface, especially the menus and dialog windows (including dialog elements such as checkboxes, drop-down lists, and buttons). Strings that the software displays under certain conditions, such as error and status messages, also need to be localized. Moreover, the software localization may also comprise keyboard shortcut for executing certain functions as well as version information. The version information contains basic information on the software, e.g. copyright information, the product name, and of course the version of the file or product. This information can be accessed by opening the properties of the respective file.

Computer-Aided Software Localization

The localization of software usually takes place with the help of computers and software, e.g. special software localization tools or conventional translation management systems. Both types of software work in the same way: The software extracts the content to be localized from the program code. Simply stated, the program code consists of the commands that are written in the programming language of the software.

The WYSIWYG Mode—WYSI what?

Besides text, the content to be localized may also contain information on the graphical display of the software, especially of dialog windows and their components. The so-called WYSIWYG mode can be used to ensure that the localization result is correct especially also with respect to the graphical design of the software. The acronym WYSIWYG stands for "what you see is what you get". Even while the elements of dialog windows are being localized, you can see what they will look like later on.

Apart from providing a preview and thus a visual context of the elements to be localized, the WYSIWYG mode enables the localizer to resize and reposition the graphical elements of the dialog windows. If a button is too small for the target-language designation, the button can simply be resized directly without the need for a software developer to intervene.

Common File Formats

Software usually consists of a small or large number of program files. To fully localize software, all these files need to be localized. The files can come in various formats.

Most importantly, the file formats used depend on the respective development platform or programming language. Standard Windows resources and .NET resources are widely used.

In terms of specific file formats, EXE (executable files) and DLL (program libraries) are well known. Other formats include OCX and CPL. The said formats are binary files, i.e. the files have already been compiled.

In addition to compiled formats, uncompiled formats exist as well. In these formats, the content to be localized has been extracted from the respective program files to text files. These are so-called resource script files. Common uncompiled formats include RC, RC2, and DLG.

The advantage of localizing compiled files is that the files are operable immediately upon localization, i.e. they can be used without any overhead for the software developer. By contrast, the advantage of uncompiled files is that the files can be opened and edited with any text editor. However, they need to be integrated in the program code after the localization and be compiled.

Localization content can also come in the form of exchange formats. For instance, XLIFF is a common exchange format for general translation resources. Specific exchange formats from the field of software development include PO (for Portable Object) and JSON (for JavaScript Object Notation).

First Steps

Before setting up a software localization project, a number of technical details need to be checked and clarified. This includes:

Localization files and instructions ("localization kit")

Before setting up the project, it must be checked whether all files are on hand and whether they can be handled by the utilized localization software. All files must be provided in formats that are supported by the software. It must be checked whether there are any specific contents that need to be taken into consideration (e.g. figures with text in the software). Of course, the instructions and requirements of the customer are also relevant to the success of the localization project. Often, the software manufacturer will provide all this relevant information in the form of a localization kit.


Before setting up the project, it should be clarified with the customer whether the localized software is to be tested. For this, the customer may need to provide some resources (installation files, etc.) upon completion of the project.

Customization of keyboard shortcuts

For keyboard shortcuts that are associated with software functions, it must be clarified with the customer in advance whether these are to be customized for the target language. Usually, however, keyboard shortcuts are not localized.

Tip: The default settings of the Across Translator Edition provide for the customization of keyboard shortcuts within the scope of the localization. To change this, the respective option needs to be configured in the advanced settings of the settings template of the Windows resources under Tools System Settings → Document Settings → Windows resources. To do so, click Advanced in the respective settings template and select an option (e.g. "Hidden").

Localizing Software with the Across Translator Edition

In the course of the project setup, the Across Translator Edition extracts all content to be localized from the program code. The actual program code is not touched. In this way, the translator can concentrate on what matters, and he cannot accidentally damage the software's correct functionality. In this way, localizing software is actually no rocket science. Nevertheless, a number of aspects should be remembered when localizing software.

Important: When localizing software files, it is usually not possible to generate previews. Therefore, the preview function is grayed out in the Across Translator Edition. This is because software usually consists of multiple program files, and a single program file cannot be run by itself. However, the WYSIWYG mode for the localization of dialogs delivers a real-time preview. For very simple applications that merely consist of a single executable file, it is possible to generate a WYSIWYG preview; see "Tips and Tricks" below.

Some of the aspects that specifically concern software localization:

Graphical customization of dialog elements (WYSIWYG mode) #1

Use of the so-called WYSIWYG mode (see above) is recommended for the localization of dialog windows and their components. The WYSIWYG mode is available for the source language, but most importantly also for the target language. This mode must first be activated via the  icon in the respective toolbar. The translation of the text elements takes place in the respective input field. The resizing of a dialog element (e.g. text field, drop-down list, checkbox, or button) takes place directly in the WYSIWYG view with the help of the square black handles at the corners and edges of the respective elements (as when processing images). A dialog element can be repositioned by placing the mouse cursor on the dialog element, keeping the left mouse button pressed, and dragging it to the desired position.

Tip: The quality management criteria Overlapping controls and Text bounds help to avoid errors in the graphical display of dialog elements; see "Tips and Tricks" below.

Graphical adjustment of dialog elements (WYSIWYG mode) #2

After resizing and/or repositioning a dialog element, it often no longer matches the other elements of the dialog window. To adjust them consistently, select the respective elements via multiple selection (keeping the Ctrl key pressed). Subsequently, the selected elements can be consistently positioned or resized via the respective item from the context menu, which can be opened with a right mouse click.


In the field of software localization, placeholders (e.g. %d or %s in Windows resources or {1} or {2} in .NET resources) represent certain contents, e.g. numbers and number formats (e.g. the date when a file was last changed) or names (e.g. the name of a certain file). In software texts, placeholders can occur in status and error messages. At runtime, placeholders are dynamically replaced by the current values or designations. For example, in the error message "Unable to open document %s", the placeholder %s stands for the name of the file that cannot be opened. When using the program, the placeholder is replaced by the respective name of the file that cannot be opened.

Important: When localizing software texts, make sure that the placeholders are inserted at the correct position in the translation. Normally, placeholders are inserted by manually typing them.

Tip: The quality management criterion "Placeholders" helps to avoid errors with placeholders; see "Tips and Tricks" below.


In the field of software development and localization, hotkeys or shortcut keys are keyboard shortcuts with which menu items or elements in dialog windows can be controlled or selected (e.g. Alt+F to open the File menu). Hotkeys are especially important for the accessibility of software. In the software user interface, hotkeys are displayed in the form of an underline (e.g. File); in the software, however, they are shown with a & character (ampersand, e.g. &File). When localizing software texts, it is important to take care that the hotkeys (the & characters) are inserted at the correct position in the translation.

Important: Hotkeys must not be assigned more than once in a menu or dialog window.

Tip: The quality management criterion "Hotkeys" helps to avoid errors with hotkeys; see "Tips and Tricks" below.

The control characters \n and \t

In software localization, the control character \n generally represents a line break and is contained e.g. in string tables. (However, it can also be used e.g. as a delimiter between a status bar text and the corresponding tooltip.) The control character \t stands for a tab stop and is usually used in menu items in order to physically separate the menu item from the corresponding keyboard shortcut. These control characters must also be inserted in the translation. Normally, control characters are inserted by manually typing them.

Tip: Using the \n icon, the control character \n can be displayed as a line break or as a character string in the WYSIWYG view.

Keyboard shortcuts

In the context of software localizations, keyboard shortcuts that are associated with certain functions can also be customized for the target language. The individual functions are linked to the respective keyboard shortcuts in the form of IDs. In practice, keyboard shortcuts are rarely customized. If this is to be done, the software manufacturer needs to supply all needed information, especially concerning the meaning of the IDs. In the Across Translator Edition, keyboard shortcuts can be customized in the crossView area of the same name.

Tips and Tricks

QM check

The Across Translator Edition features special quality management criteria for the localization of software files (Windows resources and .NET resources). This includes:

  • Placeholders: This QM criterion checks the correct use of placeholders.
  • Hotkeys: The QM criterion checks whether hotkeys have been used in dialog windows and menus and that they have not been used more than once.
  • Text bounds: This QM criterion makes sure that text within a control element (e.g. button) is not wider than the actual control element.
  • Overlapping controls: This QM criterion checks whether any control elements overlap with each other or with a group field (i.e. an area of a dialog window that contains several control elements).

Display of string IDs in crossView

The localization of the content of string tables can be tricky, as the strings must be translated without taking their context into consideration. In this context, the string IDs can be helpful, as they allow unique identification of the strings in coordination with the software developers. To display the string IDs in crossView (instead of the string texts), the view mode "Show string ID" can be displayed via the icon in the toolbar of the Source View/Context View.

Previews of simple applications

When localizing software, it is generally not possible to generate a preview (see above). However, an exception exists for simple applications that merely consist of a single executable file. To generate a preview in such a case, the preview settings need to be adjusted. To do so, select Executable file in the list of document formats under Tools → User Settings → General → Preview and click Edit. Then select Executable file and enter the character string "%s". Click OK to confirm the adjustment. Next, a preview of the application can be generated via the preview icon in the crossDesk toolbar.

Magnetic alignment lines for .NET resources

When localizing .NET resources, magnetic alignment lines facilitate the accurate positioning of dialog elements to the millimeter. Moreover, the position and size of the current dialog element are displayed under the Target Editor.

Stay up to date

Sign up for our newsletter to receive the latest news from Across.