Role of the Engineer in the Localization Industry

Software engineering, and more specifically localization engineering takes a certain kind of individual. It most certainly isn’t for everyone. Most people who get into the field develop an aversion to the machines after a short period of time and only use them on the clock or when asked. Their hearts may have been in the right place, but when facing the tedious, more arduous side of engineering, they’d rather be anywhere else than in front of the monitor.

The role of the engineer in the localization industry is multifaceted. Most people not in tune with the translation and localization industry may not realize this team member’s importance or even if an engineer is necessary. After all we are translating words and text. However, when you take into consideration the multiple applications in which the text can be written and the different software platforms that they can be built upon, then it’s obvious that an engineer with experience in software is necessary.

Amongst troubleshooting needs that may arise when working in different software environments, there are specific areas where an engineer lends his expertise to the localization team. Up front, prior to the project starting, the project manager and the linguist count on the engineer do perform a complete analysis of the software documentation that will be translated. This includes running the text through a software tool which compares it to existing translation memory and recognizes any repetitious segments. This leverage is used by the linguist for consistency and by the account manager for cost reduction. Also included in this analysis are specifics regarding the layout and format of the document(s). Considerations must be made if there is text within any images or graphics as part of the documentation as well as overall layout concerns, such as fonts or directionality of text, for different target languages and text.

During a project, the project manager will look to the engineer to complete the desktop publishing work, if necessary, and/or handle any web specific needs and platforms if the project calls for this. Again, handling different software language such as xml, html, RoboHelp, and others all fall under the job requirements of the localization engineer. A verifiable Jack of all Trades with the requirement of mastering each and every engineering need.

XML in the Localization industry

Extensible Markup Language (XML) is a platform-independent way to represent data. Simply put, XML enables you to create data that can be read by any application on any platform. You can even edit and create it by hand because it is based on the same tag-based technology that underlies HTML. That is why XML is considered an extensible language. Because of the freedom of the tags, however, the way in which XML must be written is very strict. Every tag must have a closing tag and all nodes must be ordered properly. If any of these rules are broken, an XML document will simply fail to function. HTML, as many have found, will work even if the document only vaguely looks like an HTML document.

XML is concerned with the electronic representation of the structure and content of information. It is a simplified subset of an ISO standard known as SGML (Standard Generalized Markup Language). Extensible Markup Language is the key to creating markups that can be used by any number of applications beyond the Web browser. In other words, XML is independent of the application that created it.

Some publishers that can import and/or export text in XML format are:

• Indesign

• QuarkXpress

• FrameMaker

• PageMaker

With XML it becomes feasible to target multiple output formats from a single XML source document.

Maybe it is a little hard to understand, but XML does not DO anything. XML was created to structure, store, and transport information. An example of an XML element is as illustrated:

XML in the Localization industry

João

Lima

The DTD is the part of an XML document that declares exactly what tags your document will have and how they will be arranged in the document. The XML document itself must then conform to the rules set by the corresponding DTD. The DTD can either be part of the XML document or it can be referenced by the XML document and really be stored in a separate file, possibly even on a different server. Using XML facilities we can:

• Customize style sheets from client’s XML DTD

• Convert from one XML DTD to another

XLIFF, which stands for XML Localization Interchange File Format, enables translators to concentrate on the text to be translated. Likewise, since it's a standard, manipulating XLIFF files makes localization engineering easier: once you have converters written for your source file formats, you can simply write new tools to deal with XLIFF and not worry about the original file format. It also supports a full localization process by providing tags and attributes for review comments, the translation status of individual strings, and metrics such as word counts of the source sentences.

One of the main problems in localizing files is the complexity of the various file formats. When a file is converted to XLIFF, the structural formatting is extracted and stored in a skeleton file. XLIFF allows many separate tools to work on files. While working on source file formats, it is not easy to have multiple tools work on the same files.

In summary, XLIFF aids localization in a number of ways.

• XLIFF removes the complexities of localizing different types of source files.

• XLIFF provides a common platform for localization tools vendors to write to, thus increasing the number of tools available.

• XLIFF highlights the parts of a file that are important to the localization process.

• XLIFF provides support to the localization process, through its commenting features, support for phases, and metrics.