Localization

Localization (l10n) is the process of making a single app multi-lingual. One of Kestrel's principal features is making the localization process much more straightforward for you.

How Kestrel Helps with l10n##

• Makes it easy to provide translation files for all your strings using XML (or any other storage method you'd like to implement, including flat files or databases)
• Handles language switching on-the-fly (but doesn't implement the UI for that)
• Automatically translates all Assets registered with your Screens during a dedicated localize() phase

Future Features

• Already implemented in a private branch, will handle automatic locale detection (with fallbacks) based on the device's OS settings.

Localization principles

• Any text that appears in you app (content, headings, menus, buttons, alerts, labels, UI elements) should be localizable (ie: NOT hard-coded in Flash)
• Any TextField or TextArea can be localized using Kestrel
• Localization can happen any time, but Kestrel has a localization phase that is the best time to populate your strings with content in the right language
• Localization is handled through the Localizer class. The Localizer is a proxy between the App and your localized content data (the "strings"). The easiest way to implement this is through XML, but other strategies are possible, by subclassing Localizer

How Localization Works in Kestrel

• All Screens and Assets have a setText() method that can be used on any TextField to populate that field. This solves many of the typographic headaches that you'll invariably encounter with Adobe AIR.
• All Screens and Assets have a localize() phase in their lifecycle that is the specific place to perform localization of all text strings on that Screen or Asset. You generally don't touch the Screen's localize() method, as it is simply responsible for calling localize() on all the Assets that are registered with that Screen.
• During (and only during) the localize() phase, your Assets get a reference to the Localizer, which you would typically extend to meet the string requirements of your app. The Localizer follows the Proxy Design Pattern and is basically the interface between your Assets and your localized strings. The default Localizer assumes your strings are stored as XML files which are read in on-demand, but you can subclass Localizer to interface with any data store you want.
• The Localizer is first instantiated during the app's initialize() phase, after the configuration is set. You must instantiate the Localizer yourself (AppBase does not currently do this for you, because use of the Localizer is entirely optional), and when you do, you may pass it a default language code (eg: "en_CA"). If you do, the Localizer will look for a language strings definition that corresponds to that code (or a fallback) and load it.
• If you implement a UI to select languages within your app, you can call AppBase.changeLanguage() passing it the new language code. This will cause Localizer to load the new language strings and re-localize the current Screen (or switch to another screen)

The "Localization" phase

There are many Phases that a Screen goes through (see "Screen Phases" elsewhere in this documentation). The Localization Phase is a phase that is performed once, every time a Screen is switched to. This is the only time that the App hands the Screen a reference to the Localizer, which is needed to translate the strings that appear on the Screen.