Flash, Air, and Mobile Application Localization
December 27, 2011 by Jon Ritzdorf
Category:
Technology,
Mobile
While Flash won’t disappear completely, the way in which it was
traditionally developed and deployed is going the way of the dodo. Being
perfectly honest, I don’t think anyone involved in localization will really
miss the “old days” of working with Flash. When clients state they have a Flash
project, it can be a cringe-inducing statement for localization agencies. It’s
not that we don’t know what to do, mind you, but all Flash is not created
equal. Pure, 100% Flash-developed content is so versatile that it can be
created in a million different ways, depending on the developer. The challenge
in terms of localization (and the inevitable sticker-shock for our clients) is
huge. Both Flash and AIR can be used to create rich, multilingual experiences,
but I think Adobe’s move makes sense both in terms of preserving battery power
on your mobile device (Flash is a well-known energy vampire) as well as helping
you keep more of your localization dollars dedicated to the translation of
content and not complex engineering tweaks.
What currently makes Flash a challenge to localize:
- It’s easy to be disorganized. You can put strings in your Flash
files, in an external customized XML file, in a web based dynamic file type
(like PHP) or use the strings panel in Flash to create content (considered a
best practice for multilingual projects). Many developers mix it up, and it
adds heavily to localization cost when strings are not consolidated in one,
easily accessible, text-based file.
- There has never really been a clear, complete set of best
practices on how to create localization-friendly and multilingual Flash. Just
to prove my point, even Adobe’s own entry on localizing Flash points out very
little and ends up leading you to look into Flex and AIR development rather
than pure, unadulterated Flash (for more detail, see this link on the Adobe Flash Platform support page).
There are random blog postings on the subject online, but nothing concrete
from Adobe saying, “When you develop Flash, strings should be set up in this
way so that you can enable multilingual deployment.” This has resulted in
developers finding a myriad of workarounds for international audiences, some of
which lead to tremendous language engineering work and generally aren’t well
documented or utilized.
- For many years, up until the recent release of Flash CS5.5 just
last year, the support for many languages was either non-existent or had to be
hacked (for example, with Arabic and other right to left languages). Finally, just
last year the Flash team introduced the genius idea of a “Text Layout
Framework” which took out a lot of the pain of localizing more complex language
scripts, but I have yet to encounter a developer who is actually using it on a
regular basis. Old habits die hard.
Why AIR could be better:
- AIR has a dedicated localization framework for building rich,
dynamic applications. Flash is relying on the AIR SDK (Software Development
Kit) for a lot of global support now. Enough said.
- AIR encourages the use of Java resource bundles (so-called
.properties files) right from the start. In general, Java bundles are
significantly easier to localize than the many ways strings can be introduced
for display in Flash. However, based on a project we saw recently, even AIR
developers can hardcode their mobile content strings making it hard to access (see summary points below).
- That said, since AIR is so new, its multilingual support is
still not all-encompassing and the jury is still out on the specifics on
how well it will work from a localization perspective, but we are thinking
positively about it.
In summary:
It’s good to remember that applications
don’t internationalize themselves. Even under AIR, with a robust, Java-based
internationalization framework in place, you still have to follow best
practices, such as making sure to keep all your text external to the code and
making use of flexible locale-based functions that can adjust things like date,
time and number formatting based on their preferences. While AIR might address
these age-old localization challenges, there may still be some adjustments
needed for mobile application localization. Contact us for more information on
doing this successfully.
Photo attribution: dudutorres