Software Localization

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).

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.

Testing

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").

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.

Placeholders

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.

Hotkeys

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.