Localizing Flash Content

by Larry Pilotto

Flash is a great tool for creating and distributing rich internet applications and engaging user experiences across the web. Because of its complexity, localizing Flash content is often needlessly difficult and time consuming. If you create Flash content that is intended to be translated, here are a few things to keep in mind to help reduce localization and translation costs.

Comment your code

The easier you can make a Flash movie to understand, the quicker and more accurately the localization process can take place.

When we first receive a Flash file, there are a number of areas we must concern ourselves with. Primarily, we need to identify where all translatable strings are. In a complex application, this can mean reviewing hundreds (or thousands!) of lines of ActionScript code. Consistently commenting any localizable strings throughout the ActionScript code makes it much quicker to identify them, and makes the process less prone to error.

After we look at the file's ActionScript, we need to identify localizable static text found within any movie clip, button, or graphic symbol. In some cases, this can mean reviewing dozens of Movie Clip timelines looking for translatable text. When the Movie Clips are nested 6-deep or more, this also becomes time consuming and error-prone. In many cases, we are not able to re-create the published Flash movie's run-time environment locally, so this search is not as simple as just playing the movie and noting where any text appears, making sure you see everything along the way.

Plan for text expansion within dynamic text fields

Assuming your file's source language is English, most target languages will require 20% to 30% more space. Make sure any dynamic text fields are scripted to autoSize in order to accommodate the expanded text length. Also, make sure there is enough room around the text field for it to expand. If the English text runs all the way to the bottom and right of the published movie, then there is not enough room - the translated text will fall below the bottom of the movie and not be visible.

Also, make sure any elements around the text field will be moved accordingly if needed. Having the text field resize dynamically is of little value if the elements around it do not follow suit. The goal should be to prevent a Flash programmer from having to go in to the file to make these kinds of manual adjustments. In some cases it could be simply moving a dynamic text field in a Movie Clip. In other cases, it could mean looking over many lines of ActionScript figuring out where to make the necessary adjustments. This further demonstrates the value of commenting your code.

Do not embed characters in dynamic text fields

There is a great feature in Flash which allows you to embed only certain characters from a font in a published Flash movie. This can really help control the file size, keeping it as small as possible. When the movie is translated, though, having only certain characters embedded in a text field is problematic, and means more work for the localization team. It requires an additional effort of going through all the text fields, identifying those fields with specific characters embedded in them, identifying which additional characters are necessary to embed, and then embedding them in the field. Depending on the number of files and fields, this can create a significant amount of work. Since Flash breaks the embedding selection process down by groups of characters, a common problem we see is that Flash files often come to us with only the Upper/Lower case alpha, numeric, and punctuation characters embedded in dynamic text fields. The localization programmer will then need to identify those fields, and embed the missing characters in them to fix any problems that will occur with missing characters in the localized file.

Escape text strings using double quotes

Though we're talking about this in the context of Flash and ActionScript localization, this can really apply to any scripting language. Languages such as French and Italian commonly use single quotes throughout sentences. Having to escape all those quotes, or switching to a double quote to encase localizable strings, can add up to quite a bit of extra work. In many cases, it is not possible, or practical, to automate the changes, and it becomes a manual search/replace process.

Take the following French text as an example:

'les problèmes inhérents à l'exécution d'une traduction de qualité, qu'il s'agisse d'un manuel d'utilisation pour un système de production d'énergie'

The script interpreter will read the first single quote it encounters as the beginning of the string, and will read the next single quote it encounters as the end of the string. It is legal to surround a nested string with the same type of quote as its containing string as long as the escape character ( \ ) precedes the nested quote. The escape character tells the script interpreter that the quote is part of the string, not the end of the string. The example above would then have to be re-written as follows:

'les problèmes inhérents à l\'exécution d\'une traduction de qualité, qu\'il s\'agisse d\'un manuel d\'utilisation pour un système de production d\'énergie'

More simply, you could switch from using single quotes to flag the beginning and end of the string to using double quotes as follows:

"les problèmes inhérents à l'exécution d'une traduction de qualité, qu'il s'agisse d'un manuel d'utilisation pour un système de production d'énergie"

Reuse localizable symbols

Symbols are reusable objects that you can use more than once in your Flash document without duplicating the asset in the file. A symbol can be as simple as a button or a graphic, or as complex as a movie clip. When you reuse a symbol, Flash creates a new instance of the original. That instance is really just a reference to the original symbol; it tells Flash to "Draw a copy of the original symbol here". You can update the appearance or behavior of all the instances of a specific symbol by editing the original. These changes are then reflected in all the instances of the symbol throughout your document.

Take full advantage of this capability. If you break apart symbols on the timeline in which they are used, localizing the symbol found in the library does not update those instances. This then becomes a manual process of localizing these "broken-apart" symbols one by one. It is much more efficient to be able to go in to the library, localize a symbol once, and have it automatically updated to reflect those changes wherever it's used. Besides the benefits of ease of re-use and updating, this is also considered a best practice as it helps reduce the published file's size. Placing any localizable symbols in their own folder within the file's library makes them much easier to identify, and helps move the process along much quicker.

Externalize as much of the text as possible

This is often a judgment call between what is practical and what is possible. It is possible to have Flash pull all the localizable strings in a movie from external files, and have the symbols that contain those localizable strings re-size, re-position, and re-align themselves on the fly. This is not always the most practical approach, though. It can add significantly to development costs. You really need to look at the added localization costs and weigh them against any additional up-front development costs. If you're targeting five languages for translation, it would be easier to justify this approach than if you were targeting only one or two languages. At some point, economy of scale would kick in and the added development costs would be less expensive than the added localization costs.


The key to controlling localization costs associated with Flash content is to author the movies in a way that prevents a Flash programmer from having to go in to the files to make any manual adjustments or corrections. Barring that, an effective way to help keep costs down is to watch out for some of the common mistakes outlined in this article. Based on experience, they are the most common causes of higher cost when it comes time to localize Flash content.

Larry Pilotto

"No two days are ever the same at Interpro. Every job has different technical requirements, deals with different source content, and is translated into different languages. The wide range of combinations these factors produce definitely keeps things interesting."