Multilingual Flash Production

A brief perspective on approaches to multilingual development and localization in Macromedia Flash.

by Brooks Kline

In the past few years Macromedia Flash has matured into a localization-friendly authoring environment, vastly increasing its power to create and deliver multilingual media content. This article is an effort to suggest an efficient methodology for handling Flash localization projects using version MX 2004 and higher.

Unicode support in the Flash authoring environment

Prior to version MX 2004, the Flash authoring environment only supported 8-bit encoded text—i.e. Flash could only grab 8-bit plain text from the clipboard, requiring authoring on a system with 'native' code page support. This made multilingual Flash authoring a cumbersome and limited process. MX 2004 introduced Unicode support, which transformed and simplified the Flash localization process by providing an internationalized development environment, and which also allows for more robust multilingual content delivery with Flash.

General Guidelines for development of multilingual projects in Flash

The most critical stage in a successful Flash localization project is proper initial development. There are many challenges for Flash developers in an international market, the most important of which is having an awareness of your target language scope and developing Flash content with localization in mind. This implies the following:

• Externalize translatable text whenever possible utilizing Flash's support for XML or text file 'includes'.
• Avoid using hard-coded translatable strings, font information, or other localization specific parameters in ActionScript.
• Internationalize any custom components.
• Manage all localizable elements properly in the Library: all translatable static text objects must be converted to symbols to allow those objects to be accessed via the library; in the library, use naming conventions and folder organization that clearly groups and identifies localizable elements (text and audio).
• Avoid 'breaking-apart' static text objects into vector graphics.
• Try to provide content layout that can accommodate text expansion.
• When using synchronized audio voice tracks in Flash, anticipate timeline scaling to accommodate potentially longer localized audio.
• When leveraging pre-MX 2004 projects migrate the source to a Unicode-based version of Flash and address any I18N issues before localization of the project.

Approaches and methods to using text in Unicode-enabled Flash

There are many things to consider in developing and localizing Flash projects in terms of the large (and growing) array of tools and objects available to use and process text. Here are some of the key aspects to consider:

Static text objects are rendered as vector graphics during compile, preserving the text and font display regardless of the target system. One substantial drawback of using static text objects is that localizing these objects involves a largely manual process of cutting and pasting to extract and replace strings. Static text objects must be converted to symbols in order to be managed effectively with the library, and the degree to which they are clearly identified and grouped will directly impact the speed and flow of the localization process (see "General Guidelines for development of multilingual projects in Flash", above).

An alternative process of localizing static text involves using tools to extract and replace strings directly from and to binary compiled Flash files (.swf); however, this method will only work for relatively simple projects that don't require re-sizing, audio synching, etc. and is not considered in the scope of this article.

Dynamic text objects are more conducive to localization as the text can be easily externalized in a variety of text formats—the most useful and powerful of which, from a localization standpoint, is XML (see below). However, with dynamic text objects the strings are rendered on the target system at runtime, and care must be taken to only use standard fonts that will be found on all target computers—or, if file size is not an issue, fonts can be embedded in the compiled .swf file.

Another issue to consider with dynamic text is that changes to the text cannot be seen until the movie is compiled and viewed in .swf format. This can increase testing and QA time, especially with longer Flash movies, as it makes re-sizing a trial-and-error process—but the benefits of this approach generally outweigh the inconveniences.

XML is a powerful tool for managing text data in a Flash project, as well as being a format that is conducive to translation. Externalizing project strings in an XML document clearly separates textual content from the presentation environment, and if used as a general methodology can clarify development roles and simplify the localization process. One thing to consider with this approach is that the xml document has to be loaded and the text data parsed at runtime, which might make this practice impractical with very large data driven projects.

Conclusion

The addition of Unicode support in Flash MX 2004 was a radical change that nullified much of the processes and workarounds previously employed by Flash developers and localizers. It is important to understand the full implications of using an internationalized authoring environment in order to fully benefit from the power of multilingual content delivery with Macromedia Flash. The main impediments to smooth and efficient Flash localization have now shifted away from the innate limitations of the authoring environment to the development and localization processes themselves: sensible and farsighted planning and execution that account for future localization are the best methods of ensuring successful deployment of multilingual Flash content.

ENLASO's Flash Solutions

For more information on how ENLASO can assist you with your multilingual Flash localization requirements, please contact Chris Raulf at: 303-516-0857 x103 or by email at craulf@translate.com