What Is Localization Engineering?

It is not translation but still very related to language. It is not engineering but still much related to building products. Localization engineering basically is taking the development environment of a product, taking it apart, and putting it together again after all the text has been translated. Actually, localization engineering is probably the main difference between localization and translation. It’s all that “technical stuff” that needs to happen when a software user interface is translated, or an online help file, or even an HTML file.

A bridge had to be built between all “technical stuff” and the translation work. This came as a fairly natural evolution as many software publishers started outsourcing more than only the translation work to “localization vendors” that clearly recognized many opportunities. Developers had to focus on making the release dates of the –normally– English products, and had no time and/or interest to deal with all the complexities of multilingual versions of the product.

Localization Engineering Tasks

Project Preparation A “localization kit” normally consists of hundreds of files, of which some are translatable and many are not. It has build environments for software applications and/or the accompanying online help files. To build a software application, you need all the resource files and code files, which are then compiled into a binary file or executable which can be run on a computer. For example, a Windows application developed using Visual C++ consists of hundreds of files with programming code, resources, and resource files. Examples of resources are the bitmaps used in toolbars, such as the printer icon which executes the Print command. In most cases, these resources do not have to be changed for any localized versions of the product. The translatable information, such as the menu text, dialog box options, and error messages, is stored in resource files, which in the Visual C++ environment normally have the .RC extension. A software product which has been well-internationalized stores all translatable text in one or more of these resource files, which makes the localization job relatively simple. However, in many cases, files containing translatable text are found all throughout the build environment.

It is the localization engineer’s responsibility to locate and identify all these translatable files and to prepare them for translation. Localization engineers should ensure that translators know exactly what they need to do, so they can get started quickly. Software localizers normally translate resource files in a translation memory tool such as TRADOS or a user interface localization tool such as Alchemy Catalyst or Passolo.

Another important activity in the project preparation phase is testing the build environment and setting up all the software required to compile the localized product. Finding out compilation errors early on in the process could prevent considerable trouble later on in the process when the localized versions of the product are compiled. This is essential for software applications as well as online help systems.

In summary, localization engineers will play an increasingly important role in making translatable information "translator-accessible". This, combined with the fact that good localization engineers are difficult to find in the marketplace, would make this career move very interesting for the more technically-savvy translators. So if you're a techie and you want to move into languages, or if you are a translator and you want to move into technology, this may very well be the dream job for you.