Besides ActionScript and MXML, there is a third source file format for which mxmlc can produce code: properties files. Thus, for FalconJx, like for MXML, we have to decide which way to go: either
1. let Falcon generate the temporary ActionScript class and compile that to JavaScript, or 2. produce JavaScript code or maybe even data (JSON?) directly from the properties file. But first, let me summarize how mxmlc handle properties files for i18n. Most of this is from the documentation on ResourceBundles<http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7fcf.html>, some facts I reverse-engineered by playing with Flex 4.6. As I don't really have practical experience with Flex and ResourceBundles, can someone please confirm or correct what I found out so far? As I understand, mxmlc takes a Foo.properties file from source path locale/{locale} (or any other pattern specified as part of the source path) and generates a class {locale}$Foo_properties for each given locale. Each of these classes is a subclass of mx.resources.ResourceBundle and calls super("{locale}", "Foo"). It overrides getContent() and returns an Object literal defining all the key/value pairs from locale/{locale}/Foo.properties. The ResourceBundle superclass registers with the singleton mx.resources.ResourceManager (interface IResourceManager implemented by ResourceManagerImpl), which, given some key, returns the right value according to its current localeChain. The annotation [ResourceBundle("Foo")] at some class Bar establishes dependencies of Bar on all ResourceBundle classes {locale}$Foo in the current locale chain. That means when mxmlc is run with locale=en_US,de_DE, both en_US$Foo and de_DE$Foo will be linked into the generated SWF, and Bar will instantiate both ...$Foo classes, so that they register with the ResourceManager and Bar can access the key/value pairs they define through ResourceManager.getInstance().getString("Foo", "text") or, in MXML, @Resource(bundle="Foo", key="text"), where the latter automatically adds the [ResourceBundle("Foo")] annotation to the class generated from the MXML file. You have two ways of deploying different locales: either compile all different locales into one SWF, or produce a separate SWF for each locale and load the one(s) needed on demand. What I did not figure out is whether it is possible / makes sense to put such generated ResourceBundle subclasses into a package. I put a properties files into a locale/{locale} subdirectory, say locale/en_US/acme/Foo.properties, and as expected, mxmlc (I used Flex 4.6) generated a class acme.en_US$Foo_properties. However, the class still registered with the ResourceManager under the name "Foo", not "acme.Foo", so my attempt to avoid name clashes (after all, that's what packages are for) was rendered void. Is there any way to put properties in a package, or is it simply not possible with mxmlc? If the latter, should we change this behavior for Apache Flex / Falcon? For FalconJx, the question is whether we want to 1. accurately mimic how mxmlc handles properties files and generate ResourceBundle subclasses that register with the ResourceManager, or whether we'd rather 2. find a more straight-forward, efficient way to get the key/values for the requested locales to the client and feed them directly into the ResourceManager. For the first approach, does Falcon already generate the temporary ResourceBundle subclass? Then we could just fetch it and compile it to JavaScript as usual. I'm sure the [ResourceBundle(...)] annotation can be implemented in Falcon to add the required dependencies on the ResourceBundle subclasses. For the second approach, we'd generate JSON files from properties files and the [ResourceBundle(...)] annotation would have to take care of loading these into the ResourceManager directly. Following the AMD approach I proposed, we could take advantage of the RequireJS i18n plugin<http://requirejs.org/docs/api.html#i18n>. However, it seems to me that Flex has a different fall-back / default semantics than RequireJS---we'll have to investigate on this. What do you think would be the better approach? Or should we try both? In both cases, we have to think about which kinds of optimized deployment we want to support. For applications that come in many different locales, linking all locales into one big JS would be quite a waste, so it should be possible to create locale bundles that are loaded depending on the user locale. Greetings, -Frank- J8)
