Why is Flash so lousy at localisation?

Saturday, May 7th, 2011 at 3:21 pm

Originally I intended this post to be a series of examples demonstrating some of the hassles involved when dealing with multi-lingual content in Flash. But it occurred to me that the issue isn’t so much that Flash is difficult for this purpose, it’s more that it’s lousy. It’s way behind the curve considering where the rest of the web is today in this regard, and incredibly the situation was far worse not much more than twelve months ago (before Adobe released Flash CS5 and the Text Layout Framework).

The rationale for this post came after attending a talk at SXSW 2011 — ‘Flash is Dead, Long Live Flash!‘. The presenters, Elliot Chong and Toby Miller, gave a great overview of strengths and weaknesses of both Flash and HTML 5. However, one point of debate they missed was localisation. Not that I expected to hear it, but I feel strongly about such things considering this is a big part of my day job. During the Q&A session, I brought up the point of localisation — but explaining technical trivialities on the spur of the moment in front of a large crowd of peers can be tricky: hence this post.

Let’s start with the simple things. Now Flash actually provides fine support for most languages — even Chinese and Japanese are OK. Until you get into complex scripts — we’re talking Arabic, Fari, Hindi, Urdu and many more. Basically any alphabet that changes the ligatures between characters, depending on the characters present.

Caveat: I’m a designer first and developer second… if I’ve got something wrong here please let me know — anything new I can learn to make my life easier is always appreciated!

So, let’s look at what problems Flash will give us trying to put Arabic text on to the stage. Let’s use the Arabic word for kitten. This is how it appears correctly rendered in plain old HTML (right aligned since Arabic is read right-to-left — another point to touch on, but we’ll get to that later).


Now, let’s try and show the same text in Flash…

Example one: classic text field (SWF size: 4kb)

The simplest way to put text on the stage in Flash is with a simple text box. Just create it on the stage, copy your text, and you’re away. But no, not with complex scripts. For some reason Flash is incapable of rendering the ligatures between characters together correctly in classic text fields. And the web is full of depressing forum posts about people enduring frustrations at what appears to be such a trivial thing.

Example two: dynamic text field (SWF size: 4kb)

Again, this renders exactly the same as example one. Having dashed your hopes of static text displaying properly, surely you didn’t expect to be able to use dynamic text fields?

Example three: Text Layout Framework (TLF) text field (SWF size: 52KB)

Hoorah! OK, so some credit to Adobe here — so you can display complex scripts properly straight on the stage. But only if you use the new Text Layout Framework, which requires Flash CS5 and Flash Player 10+. And you can expect an additional 50kb on top of the SWF size! Prior to Flash CS5′s release in April 2010, this was all but impossible: the only way to display complex scripts in Flash properly was either as a vector exported from something like Illustrator (which, by the way, has supported complex scripts for a long long time) or as a bitmap from Photoshop (again, supports complex scripts).

Example four: programmatic text field (SWF size: 52KB)

Let’s try creating the text field with ActionScript:

var myFormat:TextFormat = new TextFormat();
myFormat.color = 0x233515;
myFormat.size = 76;
myFormat.font = "Arial";
myFormat.align = TextFormatAlign.RIGHT;

var myTextField:TextField = new TextField();
myTextField.text = "القطط";
myTextField.width = 190;
myTextField.height = 100;
myTextField.selectable = true;
myTextField.y = 6;
myTextField.defaultTextFormat = myFormat;


Well, at least Flash renders the text in the correct order, but it still doesn’t correctly render the ligatures.

Example five: programmatic Text Layout Framework text field (SWF size: 112KB)

Let’s try creating the text field with ActionScript using the Text Layout Framework:

import flash.display.Sprite;
import flashx.textLayout.compose.StandardFlowComposer;
import flashx.textLayout.container.ContainerController;
import flashx.textLayout.elements.TextFlow;
import flashx.textLayout.conversion.TextConverter;
import flashx.textLayout.edit.SelectionManager;

var markup:String =
"<TextFlow xmlns='http://ns.adobe.com/textLayout/2008' fontSize='85' color='#233515' textIndent='15' paragraphSpaceAfter='15' font='Arial' paddingTop='25' paddingRight='25'>

var textFlow:TextFlow = TextConverter.importToFlow(markup,
textFlow.flowComposer.addController(new ContainerController(this, 200, 100));
textFlow.interactionManager = new SelectionManager();

Hoorah, Text Layout Framework comes through again. But look at the file size now: 112KB. That’s 28 times the size of creating a simple text field programmatically.

Of course Text Layout Framework gives you a huge amount of text control, so the larger file size is somewhat understandable — but that big? Just to render a simple word?

These are all very simple examples, but just imagine how much more complex most projects will get in Flash if localisation is required. The extra complexity (and increased file size) from using Text Layout Framework would surely discourage most developers from using it, particularly if there is no need for localisation at the beginning of the project. This introduces a potential nightmare scenario of rewriting entire applications to use Text Layout Framework.

Other gotchas with Flash and localisation

Font embedding

Embedding fonts in your project? Your standard Latin character set (which covers most European languages) is pretty light weight. Let’s look at kitten in other languages:

Example six: Latin font embedding (SWF size: 55KB)

Even adding in Latin I, Latin A and Latin B extended character sets for a font only adds about 56kb to your file (using Arial Unicode as your font). That’ll cover pretty much any Latin-based alphabet, from Icelandic through to Turkish. But now, let’s add Cyrillic and Greek.

Example seven: Latin, Cyrillic and Greek font embedding (SWF size: 85KB)

Now we’re looking at another 32kb on top — 85kb in total. Now that’s really not much… but let’s now look at Chinese and Japanese.

Example eight: Latin, Cyrillic, Greek, Simplified Chinese and Japanese font embedding (SWF size: 3.8mb)

For an embedded font that covers Latin, Cyrillic, Simplified Chinese and Japanese — you’re looking at a whopping 3.8mb.

So, if you’re planning on localising with dynamic Flash applications across many languages, you have two choices:

  1. Don’t embed fonts, just use device fonts — you’ll lose your nice text on many PCs, but your file size will be manageable
  2. Embed fonts but create different files for each language — again, file size manageable but then you’re re-creating a whole bunch of files, and maintenance can become quite a nightmare if you’re not careful

The right-to-left UI

Many right-to-left (RTL) languages are also complex scripts, so we’ve got a bit of a double-whammy here. Arabic, Farsi, Urdu… and even Hebrew (although at least that’s not a complex script!). Since RTL users read right to left, a good UI designer will re-align the interface in the same way: for instance, check out Google Israel or Google in Farsi, and notice how the entire screen is ‘flipped’ around. Even close buttons on dialogue boxes get flipped (such as this example from GNOME on Linux).

This means you should do the same for all UI inside your Flash application. While it’s a bit of a hassle at first, what I’ve found causes the most problems when doing this is Flash’s Cartesian coordinate system — X and Y works great for left-to-right, but not so for right-to-left.

Align an object to the top left? Easy:

But for RTL, we want it on the top right.

When you’re doing that for all your UI elements, it can turn into a real chore. Never mind if you run into stage.Width calculation bugs which do happen when viewing the SWF in various browsers.

What if we were developing a HTML/CSS/Javascript application instead?

.rtl #object{right:10px;}
.ltr #object{left:10px;}

Much, much easier! (Of course, there are plenty of browser bugs with CSS too, so it’s by no way perfect, but it is much better).

Flash UI Components

Using Flash’s inbuilt UI Components will cause you some problems too. You can move the scrollbar on a scrolling TLF text field to the right at least (you can do this programmatically, too):

Example nine: right-to-left scrollbar (SWF size: 119kb)

But it appears many other components (such as the combobox) have no TLF support or the ability to make them more RTL friendly (all the text below is rendered incorrectly in Arabic):

Example ten: other Flash UI components (SWF size: 49kb)


For anyone looking at creating Rich Internet Applications that will work across different locales, given the growing market acceptance of CSS3, HTML5 and already accepted tools such as jQuery, Flash is looking like a really hard task for such work.

But disregarding all those points, let’s go back to the main thrust of this post: why is Flash so lousy at localisation? There are an estimated 65 million Arabic users online, and if you want to use Flash to provide content for these users, you’re in for a ludicrous development experience. For me, it’s really not good enough. Years ago Flash was targeted as being highly inaccessible, and even though it has made good progress, it’s highly inaccessible in another way: that of localisation.

Download example Flash files from this post (1mb).

One Response to “Why is Flash so lousy at localisation?”

  1. Justin Pante says:

    Hey James,

    Good article and very in depth!

    Firstly, before I go any further I’m a Flex-dev so straight away I have a different view on the flash/actionscript paradigm. All the projects I’ve worked on involved building feature rich clients with less emphasis on application size and initial download (within reason). The key thing to remember though is flex is flash

    Since it’s inception in 2004 Flex was always coined as an enterprise SDK aimed at giving developers the ability to access a host of libraries built on top of the flash platform to build Rich and responsive user experiences.

    The problem with this of course is that shared libraries are definitely heavy compared to the traditional Flash application, but in the scope of things what is 400kb when you have web moguls like YouTube pushing terabytes of data every day? As internet speeds increase the focus on pursuing a low bandwidth website will decrease.

    Having said that, the Flex SDK is now geared so it can be cached. If an application is set up correctly the SDK can be stored on the users machine as a set of runtime shared libraries and only needs to be downloaded once. Once for any application using that particular version of the SDK.

    The Flex SDK is amazingly powerful. It provides a lot more support for right to left functionality all built on the basics with TLF that you described. Flex has greater control on component and element positioning with all components including buttons, labels, text boxes, lists etc. supporting rtl. In addition to this All UI components in flex have left, right, top and bottom styles, similar to CSS. This removes the need to calculate position based on screen and container widths.

    On top of this many libraries have been developed for mirroring layouts. The following link http://opensource.adobe.com/wiki/display/flexsdk/Layout+Mirroring show’s a library that can be included to combat the need to have to apply styles to every component to mirror it for rtl translation.

    Fonts are interesting… Especially double byte fonts like Chinese. They are by nature HUGE :) and embedding them can become a real mess. On projects in the past when we’ve worked with localisation we’ve leveraged the ability for Flex to pull in stylesheets at run-time. Fonts are compiled in separate swfs and only then loaded in if required by the user. That way the base application is relatively light and only the fonts required are downloaded and applied to the app.

    However, All this is GREAT if you’re building applications that are by definition feature rich and there is a level of expectation that they’re going to be fat clients (UI clients not people clients :) )

    I can definitely see why in the case of a quick use of rtl text the flex SDK and associated libraries can be overkill.

    At the end of the day it’s all about what the requirements are :)



Leave a Reply

Current month ye@r day *