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.
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