TODAY, IN TRANSLATION TIMES.


An Overview of Globalization (Part I of III)

MultiLing Works with Thermo Nicolet to Achieve High-Quality Scientific Translation

DTP Tip: Using Data-Driven Graphics in Adobe® Illustrator® 10

Transit Tip: Moving Tags

To successfully compete in international markets, software must easily accommodate differences in language, culture, and hardware. Globalization is the process of making a product multilingual. In more detailed terms, it is the process of developing a program core whose features and code design are not based on a single language or locale, and whose source code base simplifies the creation of different language editions of a program.

Creating global software code involves more than extracting and translating the text from the software application or operating system into the local language, a process generally referred to as localization. In globalization, the goal is to provide software that is so "acceptable" to the local culture and language of the end user that the end user would consider the software to be a native product. Users expect software to support the same set of features as the native language edition of the product does, and they expect it to achieve the same level of quality. Users also expect local formatting for items such as dates and times (the way the date or time is written), currencies (type of icons and punctutation used), numbers, and units of measure. For enterprise solutions, the end user may also expect that he/she is able to share data across a system that extends over several countries, languages, operating systems, and hardware platforms.

In the United States, the current approach to globalization used by many companies is to "adapt" the software product to specific markets by translating and re-engineering the software to replace the U.S. bias with the local country bias. This method is time-consuming, costly, and inefficient as it requires a completely different iteration of the software for each language and/or culture. This approach is slowly being replaced by a two-step process of internationalization followed by localization. Internationalization involves identifying culturally and linguistically dependent features of the program, and making sure all such features do not exist in the source code. This process is generally complex (most developers and managers grossly underestimate the level of effort required to create high quality, foreign language editions of a product), but can be much simpler if the original program is designed with globalization in mind. Once the source code is internationalized, some customization may be required; however, even with this extra effort, this process is still much more efficient than globalization forced through localization.

As stated previously, for effective internationalization to occur, culturally dependent features should not be hard coded (included in the source code). Isolating and marking language and cultural dependencies is a very difficult process as often times few features exist that are not culturally specific. However, identifying the right level of globalization for the product will help ensure that you meet your customers' needs and objectives without doing excessive and unnecessary work.

Key factors to consider in your product's architecture include the following:

1. User-interfaces: help screens, menus, screen prompts, error messages, graphics, templates, models, scenarios

• User interface elements (text, strings, bitmaps, icons, accelerators, etc.) are isolated from the source code.
• Strings and/or characters that should not be localized are marked as such (i.e. protected through the use of a QA system, such as Transit).
• Text is isolated from the bitmaps and icons.
• Code does not contain hard-coded elements such as character constants, numeric constants, other strings, screen positions, filenames, pathnames, etc.; and these elements do not presume a particular language.
• Localizable elements are isolated into resource files, and compile dependencies are minimized.
• International editions of the program are compiled from one set of source files (the code may need to be altered for some language editions, such as Middle Eastern languages, because they require extra processing).
• Code uses generic data types and generic function prototypes.
• Menu and dialog-box accelerators are unique.
• Language editions using double-byte character sets are based on a single executable.
• Language editions using Unicode are based on a single executable.
• Bi-directional language editions are based on a single executable.
• Language editions share a common file format.

2. Character classification and transliteration: capitalization, hyphenation, finding boundaries between words and lines

• Segmenting algorithms are sensitive to languages and locales.
• Capitalization and punctuation are sensitive to languages and locales.

3. Collating or sorting

• Sorting algorithms and case conversion are sensitive to languages and locales.

• Sorting alphabetically vs. sorting by radical or number of strokes for ideographic languages such as Japanese or Chinese.

4. Notation conventions: format of numbers, currency, time, date, addresses, phone numbers, etc.

• Data is properly formatted for display according to the user's locale settings.
• If dynamically constructed strings must be created, the positions or parameters for the strings are not hard-coded (e.g. date formats).
• Application considers other date settings when necessary, such as the Imperial calendar or another calendar system.
• Address fields are generic or dynamically allocated, and Postal Code fields have no particular format or length.
• Phone number fields are long enough for any international phone numbers.
• If times are given, time zones should generally be included.

• Dates: 2/15/72 vs. 15.2.72, Times: 5:30 P.M. vs. 17:30 (to avoid confusion with dates, it may be better to write a date as February 15, 1972 or 15-Feb-72, which is more universally understood).
• Time zone acronyms, such as EST (Eastern Standard Time), should be completely written out. For an international audience, it may be better to include GMT (Greenwich Mean Time) time as well, as shown in the following example: Office Hours 8 - 17 Eastern Standard Time (GMT -6).
• Monetary formats and conversions: $1,495.00 vs. ₤962.18.
• The use of a decimal separator. The use of the period and the comma is interchanged throughout the world, as in the following example: 4,329.00 vs. 4.329,00.
• In some areas of the world, the local phone number can be more than 10 digits long. Some countries not only use area codes, but region codes as well. When displaying phone numbers for an international audience, use the ISO standard, as in this example: +1 (801) 555-5555.
• Many software products designed in the U.S. assume that every country in the world has the same address convention. This is a very poor practice, as almost no other country has the same address format as the U.S., as in the example below:


A better solution is to provide open text fields for the user to enter a valid address, such as in the example below:

Thermo Nicolet, a Thermo Electron business, has recently concluded a study involving their translation requirements. Thermo Electron is a $2.2 billion provider of technology-based instruments, components, and systems. Thermo Electron offers total solutions for markets ranging from life sciences to telecommunications to food, drug, and beverage production. More information on this study can be found at www.multiling.com/news.

With the release of Adobe® Illustrator® 10 comes a new feature that may eliminate the need for the tedious cut-and-paste routine of text in vector graphics. This new feature, called data-driven graphics, gives you the ability to create a template file for Illustrator, after which Illustrator will make the text and graphic changes according to your specifications.

For example, you may have 100 different vector images that need to be translated into seven different languages. Traditionally, this meant that the desktop publisher had to extract all of the text from the graphics into another file that was then sent to translation. After translation, the desktop publisher had to cut and paste the translated text into the 700 different illustrations (taking all of the languages into consideration). This process often took weeks for medium- to large-sized projects.

With this new feature in Illustrator, weeks of work often become hours of work. In Illustrator, you can simply mark the text as a variable field and export the text as a data set in XML format. The XML file can then be translated and re-imported back into Illustrator. In the case of our previous example, all seven languages could be linked to the same illustration by simply choosing which language in the data set to use. This does not completely eliminate desktop publishing for illustrations, as some illustrations may require resizing or similar manipulation; however, it does allow the desktop publisher to enter the translation into the graphics without having any knowledge of the translated language. In comparison to the cut-and-paste method, where the desktop publisher may need to constantly consult with the translator to make sure that he/she is entering the correct text into the illustration, using data-driven illustrations can save hours or even days in desktop publishing.

Adobe Illustrator does not limit its data-driven capabilities to text only. You can also do similar exports of graphics, graph data, linked files, and visibility properties.

In MultiLing Corporation's initial testing of this new feature, we have found one bug in the process. Illustrator is unable to import data with extended characters (characters with diacritical marks). The consequence of this bug is that a translator will need to review the final document, which should normally be done anyway, and insert any missing characters. Even with this bug, you should still save significant time over the cut-and-paste method. Non-Roman based languages, such as Asian languages, are currently being tested.

For more information on Illustrator 10 and data-driven graphics see:
http://www.adobe.com/products/illustrator/pdfs/ai10_brochure.pdf

Question:
I know how to move tags by turning off the tag protection and doing a cut-and-paste, but is there any easier way to move tags?

Answer:
An easier way to move tags is by simply clicking your mouse on the tag, then, while holding down the "Alt" button and the left-mouse button, you can drag the tag with your mouse to the new location.