Forty-Fifth Edition - Beyond Translation⁽¹⁾ – Software Localization

Although English continues to be the dominant language for software applications, software developers are increasingly interested in tapping new into opportunities in the global market with applications adapted to a multicultural, multilingual audience. Making a product linguistically and culturally appropriate to the target locale (country/region and language) where it will be used and sold is called localization, and when the product is software, software localization.

Ideally, the process of localizing software begins at the moment when the program and the associated documentation are initially designed and developed. The resulting product should be able to handle multiple languages and cultural conventions without the need for re-design. In the industry, this is called globalization.

The goal of software localization is to develop multilingual applications that offer a consistent ‘look and feel’ and functionality across all language versions. Consistent terminology is also a key success factor. The purpose of this newsletter is to provide a very brief introduction to the software localization process.

The Software Localization Process - An Overview

What needs to be translated?

In general, the process of localizing software includes the translation of the GUI (Graphical User Interface) components of the software and all associated documentation (Online Help, and user instructions). Included are:
 

	Menus: A menu is a list of options from which you can make a selection and then perform a desired action, such as choosing a command (like Save As) or applying a particular format to part of a document (source: Microsoft). It can take the form of a listing of major categories with subcategories under it.
	Dialog boxes: A dialog box is a small window that appears on the screen to request input from the user or provide information to the user. It typically allows users to change options or settings.
	Strings: A string is a sequence of characters. Depending on the implementation, strings may contain error messages, alerts, status messages, questions, tips, etc., used in the application. The translation of user interface strings is the most challenging because, unlike menus and dialog boxes where the translators are able to see the text in context, software strings usually lack contextual information.
	Pop-up Tool Tips: These are pop-ups that come up when the user runs the mouse over a button. In some cases, the text for these pop-ups is contained in separate files.

Refer to the screen below for an illustration of translatable software components. As you can see, they include the document title, menu tree, dialog box title, dialog box options and fields as well as buttons.
 

What may not need to be localized:
 

System Messages: Messages such as “Do you want to continue?” “Do you want to cancel?” may be embedded in the user's operating system, so they will be automatically localized based on the language setting of the OS. If this is the case, these messages do not need to be pulled out and submitted for translation.

Submitting Files for Translation

Since the associated documentation usually contains many references to the software, it is recommended to begin the software localization project with the translation and review of the User Interface.

Software files can be submitted for translation in various formats requiring different tools for editing. The choice of editing tool is usually determined by the software developers. The following are some examples:

	Resource files (.rc or .dlg files) are text-only files that contain all translatable software components, such as menus, dialog boxes, messages, etc. The translatable text in the software components can be edited with a text editor or word-processing program, such as Microsoft Word. After translation, the files need to be compiled into binary program.
	Compiled program files (.dll and exe) are binary files that contain the software components. The translatable text in these components may be accessed with a software localization program or resource editor. The advantage of working directly with the compiled program files is that it is possible for the localizers to see how text expansion will affect the layout of the user interface.
	Spreadsheets: Text may be extracted from the software components by the software developers and organized into a spreadsheet. When the translation is finished, the process is reversed to integrate the translations into the software.

In general, the software localization process requires the use of one of these tools:

	Text editor
	Resource editor
	Translation Memory tool
	Software localization tool

Regardless of the tool selected, it is important to filter to the user interface elements and encoding, so translators can access only the translatable text.

Software Resource Editors

These are utilities that facilitate viewing and editing resources in binary files. They may also include a resource script compiler and decompiler. There are a number of these utilities available - some are shareware.

Software localization tools

These tools typically support the editing of both text-only resource files (such as .rc or .dlg files) and compiled program files (such as .exe or .dll). They also provide:

	Translation memory and glossary development capabilities
	Spell checking and validation functionality
	Filters for software code
	Markers that indicate which strings have already been reviewed and approved, which ones have been reused from a previous translation and which ones are new and require review.

Translation Memory (TM) tools

These tools, such as TRADOS and Alchemy Catalyst, are used to create a Database of translated software terms that can be applied to the translation of future versions. This not only saves translation cost and time, but also facilitates the process of ensuring the consistency of terminology that is key to the success of a software localization project.
(For more information on TM tools, please refer to our html presentation)

Editing Resource Files - A few editing guidelines

Quotation marks: Software developers usually place text strings within quotation marks. Therefore, the use of quotation marks within strings should be avoided. If you must use quotation marks within strings, such as in (“Click "Quit" to exit"), use a different notation, such as double quotes ("Click ""Quit"" to exit") or \” ("Click \"Start\" to enter"). It is also important to ensure that all leading and trailing quotation marks are left intact, as well as leading and trailing spaces. Removing the trailing space from "Quitter " could produce “Quitterinstallation”.

Ampersands (&): These are reserved for hotkeys (&Schließen, &Fermer, &Close) therefore they should be avoided in running text. If it is necessary to use “&” to shorten the text in a button, for example, use a different notation, such as “&&”.

Do not translate (unless otherwise requested by the software developers):

	File names and extensions (e.g. readme.txt)
	Strings defining the date and time format, such as “mm/dd/yyy hh:mm AM/PM”
	Words in all caps, such as "RUNTIME", "STRINGTABLE"
	Words joined with an “_”, such as "visible_in_edit", "value_name"
	Words joined together, such as "SysAdmin", "valuedesc" (they may be used as “place holders”)

Quality Review

After translation, the software should be carefully tested. The user interface usually has a complex structure and contains a lot of text. Therefore, to ensure that all files are located and tested, localization testing should be performed using a tree structure or flowchart provided by the software developers.

Localization testing includes:

	Linguistic Testing
	Cosmetic Testing
	Functionality Testing
	Delivery Testing

Linguistic Testing: Focuses on the language aspects of the localized application and includes verifying that:

	the translation is complete and makes sense when viewed in context.
	text in dialog boxes and menus is not truncated.
	grammar, spelling and punctuation are correct.
	all text wraps, sorts and hyphenates according to the rules of the target language.
	accented characters display and print correctly.
	hotkey or control key assignments are consistent with operating system standards.
	concatenated strings and strings with variables display correctly in the running application.
	icons or graphics are appropriate for the target language market.

Cosmetic Testing: Focuses on the appearance of the localized application, such as dialog boxes, menus, reports and messages. It includes verifying that:

	the localized version includes the menus, options and commands as the source version. all extended characters display correctly (some languages, such as Japanese and Chinese, use character sets that are larger than the range of values of type char.)
	the text in dialog boxes, buttons, menus, etc., is not truncated.
	hotkeys in dialog boxes and menus are not duplicated.
	all user interface items, such as menus, messages, dialog boxes, fit in the screen at all required resolutions.
	the visual aspects of the application are aesthetically acceptable; i.e., buttons are properly aligned, control boxes and buttons are consistently sized; the tab order of options in the dialog boxes matches the order of the source application, and so on.
	regional settings are correct for the targeted locale, i.e., decimal separators, date and time formats, etc.

Functionality/Compatibility Testing: Focuses on finding bugs in the localized application. This is not a standard task in a software localization project, and does not have to be performed by the localizers. Clients may select to use their own software testers. This type of testing is not concerned with the linguistic aspects of the localized application, but with the code. Testers check the software compatibility with other localized versions to ensure that the target application mirrors the functions of the source language software.

Delivery Testing: Consists in verifying the functionality of the deliverable, and that all client-instructions have been followed, all updates have been implemented and all deliverable requirements such as file formats and file and folder structures, have been met.

References: "A Practical Guide to Localization", by Bert Esselink


⁽¹⁾ Editor’s Note: This is the first newsletter of a new category - “Beyond Translation”. It will focus on the challenges of merging translation and technology, for example in the localization of interactive products, such as software, games, and websites. This category will include also articles on productivity-enhancing tools and technologies applicable to the translation of publications created with high-end publishing softwares, such as QuarkXpress and InDesign.)