Worldwide Lingo

Worldwide Lingo
By Phillip Kerman

Presentation Highlights:

"It Cost More, but it’s Worth it"
Making a project that’s easily localized involves more planning and initial production. The increased investment is recovered when the savings realized in subsequent language versions is multiplied by the number of languages produced. Even when the initial production costs 100% more, if this results in a 20% savings for each extra language produced then the investment becomes a savings after five language versions.

"Multilingual vs. Localized"
A multilingual project supports more than one language simultaneously. A localized project has no indication that it was translated—to the viewer, it looks like it was made for their language. Since people don’t usually switch languages suddenly, multilingual features are best suited only for the purpose of saving distribution costs or for public kiosks.

"Why Separate Code from Data?"
Code - Data separation means separating all content which is language specific (the data) from a single source file (the code). The alternative is to complete one language, duplicate all files and individually edit each aspect which is language specific—then repeat the process for every additional language. Keeping one code file and separate data files involves more planning and discipline, but the benefits are wide-reaching and apply to single language projects as well.

Benefits of Separate Code and Data:

Maintainability
Only one source to maintain. Making changes involves making the change once.

Security
Better security because localizers are going to edit data only. People translating content will only need access to the data files. You can provide a "protected" source file with which they can test and view the data files created.

Quality
Since fixes only have to be done once, there are fewer occasions for errors.

Ramifications for Everyone:

New Skills for the Author
Good multimedia authors can recognize if an image is off by 1 pixel, similarly they need to begin separating language specific content from generic content. Even if a project is not intended to be translated, authors can be aware of how well something could be localized. It’s much easier to plan from the beginning than to try to change a project later.

Translating is Not Enough–Localizers must be culturally aware and know when to transliterate.
Being culturally aware means not taking anything for granted. School buses, for example, are not big and yellow everywhere in the world. Dialect can vary within one country—American Spanish for breast cancer is cáncer de mama in Texas and cáncer de seno in California. Since brand names often have no substitute in other languages, sometimes you must transliterate.

These examples demonstrate the need for good localizers:
The Ghanan pepper sauce named Shitto and the Japanese sports drink Pocari Sweat are some bad transliterations.
When Elaine Steinbeck asked a Tokyo bookstore if they had any books by her husband John, they said "We have his most famous book, it’s called ‘The Angry Raisins’." (The Grapes of Wrath)
A sign in a Copenhagen airline ticket office said: We take your bags and send them in all directions.
A Swiss restaurant’s menu: Our wines leave you nothing to hope for.

Lingo Tricks and Other Techniques:

Technique Advantages Disadvantages

External Media
(Keep data files external to your code file.) Images, audio, and video remain in their native format and maintain their relative path location.
Localizers don’t need to use Director.
Text files will work for record keeping (e.g. ini files). However, on-screen text (or fields) need to be created in Director for languages using double-byte character sets or even some special characters of other languages. (If this is not an issue, be aware of three "string" formats which vary: Date, currency, and decimal/comma separators.)
Every linked cast member has to be present when you open the Director file. Additionally, each link capitalizes resources and will affect performance adversely. Avoid theses issues by using "set the filename of member…" to link dynamically.

External Casts by Member Name
(Use external casts and have Director puppet sprites to "set the member of sprite…".) Localizers simply import media into Director casts and name the members appropriately. Editing unlinked external casts requires no work in the score. The localizers must own and use Director.
Image files must have the same registration point. To assure this: create all graphics at full screen—even for a tiny button—have the artist create a full screen graphic. When you bring the graphic into Director, trim the excess (by drawing a solid white box from the outside in until you trim what you don’t need). Everything will have a "loc" of the center of the screen (point(320,240) —for 640x480). Since Director "shrinks" down to the non-white borders of your image, be careful to have something that’s off white in the corners (you could put registration dots in the corners).

External Casts by Member Location
(Use external casts and use Director’s score. Put images in cast in the order they appear.) Localizers simply import media into Director casts and put the members in the right order.This is less work than having to name every member correctly. It makes the most sense for images in sequential portions of your project. The localizers must own and use Director.Registration issues (see above).Upon opening your code file, if you see the dialog "Cast members in the linked cast may have moved…" then there were some errors. If you choose "adjust score references" your code file will be linked to each cast differently. (Choose "Don’t Adjust" and close without saving.)

Reducing Distribution Costs:
We have seen ways to reduce production costs, but what about translation and distribution which are considered fixed costs? You can reduce distribution costs by including multiple language versions on one CDROM.

A multilingual installer is all but certain—though you could associate a language with a range of serial numbers (easier said than done). Regardless, the installer must make some "ini" settings, then our one code file can determine which casts and media files (data) with which to link. It’s helpful to have our code file linked to data in a dummy "language 0" folder by default…and then at runtime, change the links to the user’s language.

"Proofing" the Localizer’s Work:
Taken from the quality assurance theory of Poka-Yoke (POH-kah YOH-kay ) is the idea of designing systems which can either detect errors or prevent errors. Applied to multimedia projects, this can mean writing a Lingo script which will prove if all the external media files are present—instead of running each language version and trying to see if everything is there.

Thanks to those who helped with this presentation:
Keith Feher and Tom Burghardt at Intel’s User-Centered Design Department (Hillsboro, Oregon)
Luke Duran at Corporate Translation Services (Vancouver, Washington)
Diana Bauer at Artemus Productions (Portland, Oregon)
Mr. Jellybelly at Herman Goelitz, Inc. (Fairfield, California)

Back to Home Page
email now!

Phillip Kerman - Phone:(503) 236-7721

Last update: 25 September 1998

Technique	Advantages	Disadvantages
External Media (Keep data files external to your code file.)	Images, audio, and video remain in their native format and maintain their relative path location. Localizers don’t need to use Director.	Text files will work for record keeping (e.g. ini files). However, on-screen text (or fields) need to be created in Director for languages using double-byte character sets or even some special characters of other languages. (If this is not an issue, be aware of three "string" formats which vary: Date, currency, and decimal/comma separators.) Every linked cast member has to be present when you open the Director file. Additionally, each link capitalizes resources and will affect performance adversely. Avoid theses issues by using "set the filename of member…" to link dynamically.
External Casts by Member Name (Use external casts and have Director puppet sprites to "set the member of sprite…".)	Localizers simply import media into Director casts and name the members appropriately. Editing unlinked external casts requires no work in the score.	The localizers must own and use Director. Image files must have the same registration point. To assure this: create all graphics at full screen—even for a tiny button—have the artist create a full screen graphic. When you bring the graphic into Director, trim the excess (by drawing a solid white box from the outside in until you trim what you don’t need). Everything will have a "loc" of the center of the screen (point(320,240) —for 640x480). Since Director "shrinks" down to the non-white borders of your image, be careful to have something that’s off white in the corners (you could put registration dots in the corners).
External Casts by Member Location (Use external casts and use Director’s score. Put images in cast in the order they appear.)	Localizers simply import media into Director casts and put the members in the right order.This is less work than having to name every member correctly. It makes the most sense for images in sequential portions of your project.	The localizers must own and use Director.Registration issues (see above).Upon opening your code file, if you see the dialog "Cast members in the linked cast may have moved…" then there were some errors. If you choose "adjust score references" your code file will be linked to each cast differently. (Choose "Don’t Adjust" and close without saving.)