Considerations for localizing Flash Lite content

In this section I'll describe some of the issues that frequently occur when translating text and localizing mobile content. As you prepare your Flash Lite application to make it accessible to non-English speaking users, you'll want to consider several aspects of development, such as compensating for longer lengths of the translated text, detecting the version of Flash Lite that is being used to display your content, and choosing fonts that render the target languages successfully. If you are building a new Flash Lite application, it is very helpful to identify the language requirements early in the pre-planning stage. This will make the localization process much easier later.

I'll begin by discussing the issue of reserving the extra screen space needed to display the text in various languages. If you've downloaded the sample files provided on the first page of this article,  you can follow along with this section by opening the folder named Text Expansion Issue.

Text Expansion

Text expansion is perhaps the most common issue that you will face during the localization process. It is a known fact that different language translations of the same content result in strings of text with varying lengths. For example, a French translation of an English sentence is usually expected to result in a wider length of text, while the same sentence translated in Chinese often takes much less space. Many European languages can expand lines of text by as much as 25% when compared to the English language version.

The examples below illustrate how the same text translated into different languages is displayed using different amounts of horizontal space (see Figure 1).

Figure 1. Different translations of the same text can result in differing text lengths

The issue of text expansion becomes even more evident when you are attempting to render localized text in Flash Lite applications. Since Flash Lite is designed to target small screen mobile devices, the goal of fitting different lengths of text into the same tiny area of screen real estate becomes even more challenging (see Figure 2).

Figure 2. It can be difficult to fit translated text in the available screen area

It is a best practice to include extra space when designing the layout for mobile content to compensate for text expansion. You can also present localized mobile content by enabling scrollbars on all text elements, so that the view can expand when necessary without overflowing the screen with content. In some cases, you can also implement dynamic positioning of the stage elements based on the available space, too.

Working with different Flash Lite-enabled devices

Although Flash Lite 3 is the most recent player version, the majority of mobile device users currently own handsets that only support Flash Lite 1.1. However, this will change in the near future because the proportion of handsets that support higher version of the Flash Lite Player are increasing rapidly and the trend of mobile device usage continues to accelerate.

Since different versions of Flash Lite have different capabilities in regards to rendering the mobile content, the very first step towards localizing Flash Lite content for mobile devices is to detect which version of the Flash Lite Player is being used. By implementing player detection, you can then load the corresponding version of Flash Lite content to ensure it is rendered properly. Understanding the rendering differences and targeting a specific Flash Lite version greatly influences your localization process. Depending on the version of the player you are targeting, you should tailor your localization plan to fit accordingly.

For example, Flash Lite 1.1 does not support the ability to load XML files. This means that if you are targeting Flash Lite 1.1-enabled devices, you cannot plan to use XML as an external data source for your applications. This is true even when your Flash Lite application loads external images. If the device you are targeting only supports Flash Lite 1.1, then the device is unable to load JPG, GIF and PNG files directly. Instead, you must publish images as Flash Lite files in order to load them in Flash Lite 1.1.

Conversely, if the device you are targeting supports Flash Lite 2.x or 3.x, you can load localized images via XML. This means you need to implement some kind of player version detection in your Flash Lite application. If you perform player detection, the Flash Lite application can load the appropriate Flash file or image format (depending on the functionality that is supported). All these factors will impact your decisions regarding localization.

Flash Lite Players are backwards compatible. That means that higher version players can render content designed for lower versions of the player. Because the players are backwards compatible, we can take advantage of this by creating a SWF file in the lowest version of Flash Lite that supports external data loading (Flash Lite 1.1). The Flash Lite 1.1 player can then be used as the player version detector for the mobile content. 

You can use the getVersion()method to detect the Flash version. The method returns a string containing the Flash Player version and the platform information. A typical string that will be returned for a device using Flash Lite 2.0 will look like FL 7,1,0,197.  FL stands for the Player platform and 7 refers to the major version of the player (see Figure 3).

Figure 3. The getVersion method returns the player version information

If you are following along with the sample files, open the folder named Flash Lite Version Detector to review the example.

The following list contains the platform and player information for Flash Lite Players (see Figure 4).

Figure 4. The Flash Lite Player versions and corresponding player platforms

Text rendering and font issues

There are several strategies you can use when developing mobile applications to make Flash Lite render different types of fonts. For example, Flash Lite applications support the use of Unicode and you can also embed custom fonts when you publish SWF files. Flash Lite supports Left to Right Language (LTR) text rendering, but does not support Right-to-Left (RTL) text display. As you review the available options, it can be confusing to identify which method is the best to use in order to ensure proper text rendering in Flash Lite content.

Some languages also have complex rendering requirements, such as Indic or South East Asian languages, which might not render properly in Flash Lite.

It is always a best practice to separate the data and presentation layers in your applications in order to streamline the localization process. In Flash Lite, you can use external XML and text files to load the text data, which can then be rendered by the player depending on the code page Boolean value operating system that runs the application. Flash Lite 2.x is based on Flash Player 7 and it supports the System.useCodepage property (in Flash Player this property has been supported since Flash MX). Flash Lite 1.x is based on Flash Player 4  and does not support the System.useCodepage property, which means it does not support UTF -8 character sets and Unicode. When System.useCodepage is set to false, the Flash Lite 2.x and 3.x players interpret external text files as Unicode. (As long as you encode the text files as Unicode when you save them.) When the property is set to true, the Flash Lite 2.x and 3.x players interpret external text files using the traditional code page of the operating system running the player.

You can see the difference when you display some special characters (Unicode/UTF-8 characters) in a dynamic text field and publish it in different versions of Flash Lite Player (see Figure 5).

Figure 5. Unicode characters display differently depending on the version of Flash Lite used to render them

Note: If you are following along with the provided sample files, open the folder named Flash Lite Unicode Test to review the example.

Before you begin to develop a localized application you need to answer many questions before deciding which type of font rendering method to use. These questions include the following:

Which languages are you targeting?

Are you only targeting European languages?

Do you plan on including Asian and Indies languages?

Will your application display bi-directional (BiDi) languages?

Are all the target languages available in Unicode, or do you need to embed special fonts into your application?

Determining the answers to the questions listed above will provide you with the information you need to start planning the layout and your text rendering strategies. If you are planning to localize your application in a language that is not available in Unicode, then you will have to embed the font in your Flash project. If you've embedded the fonts for Chinese, then you cannot render German text in the same text field. And there are other factors to consider because when you embed the fonts you automatically increase the file size. After researching all of the available options and downsides to each, you can plan the workaround to optimize your files.

To research further, open the sample Unicode-based application in the folder named Sample Folder Structure for different languages.

When possible, using Unicode is often your best bet to ensure consistent text display and maintain the application's layout (see Figure 6).

Figure 6. Use Unicode to display different languages to keep the file size smaller

Use the following guidelines when selecting the method for displaying localized fonts:

1. Flash Lite 1.x movies: Embed the fonts if you do not anticipate that they will be available at the time the movie is played.
2. Flash Lite 2.x and 3.x movies: If your text content uses fonts that are not in Unicode then you'll need to embed these glyphs into the Flash movie to make them accessible to the player at the time of playing. For example, if you want to create content in Hindi (Indian language), you'll need to embed a Hindi support font into the movie.

Conversely, if your text content uses fonts that are in Unicode, you don't need to embed the glyphs because you can take advantage of the Unicode support, which includes extended Latin scripts and Arabic languages (see Figure 7).

Figure 7. You can embed the fonts for languages not available in Unicode, but you'll increase the file size of your application

Your localization projects become more complex when you are required to support the rendering of bi-directional (BiDi) text for languages like Arabic and Hebrew. Unlike most other languages, bi-directional text is displayed and read from right to left. And these languages may also include characters that are written left to right. Later in this article, I'll offer some suggestions for dealing with issues that arise when localizing Flash Lite content using bi-directional languages.

In the next section, I'll cover how to separate the application data from the presentation layers in order to allow for localization of the text.

Page 2 of 5

Previous Page

Next Page