I18n in Flex 3 ... pros and cons

I've just spent a bit of time today researching the options for internationalising a big flex project that we're currently working on and I'm going to use this post to analyse the features built into Flex 3 for I18N and compare them with the requirements of the project. I'm not going to regurgitate the docs, just give a high level overview. There is a great chapter in the Flex 3 Developers guide that explains it all very clearly.

Firstly, I'd like to say that I'm pretty impressed with the way I18N is handled in Flex 3. It's a big step up from Flex 2. Also, if I am mistaken in anything I say I'd welcome anyone to set me straight.. I think I have a pretty good understanding of it though, so here goes.

Basically, all UI components in Flex maintain a reference to a singleton ResourceManager component. All resource bundles are loaded into this resource manager either at compile time or at run time where they can be retrieved for use in your application. Retrieving the localised strings is pretty straight forward. It's simply a matter of calling this.resourceManager.getString("bundleName","key").

Flex 3 also supports storing data types other than strings in properties files and has the relevant getters to retrieve those data types. i.e. getString(), getStringArray(), getNumber(), getInt() getUint(), getBoolean(), and getClass()

MINIMUM=5 IMAGE=Embed("image.jpg") BUTTON_SKIN=ClassReference("skins.ButtonSkin_en_US")

The next little gem is the localeChain property. Rather than setting the current locale for your application state, this property allows you to specify a cascading list of locales. The resourceManager will sequentially search for your key until it finds a match .. i.e. If your resource key isn't found in the first locale's bundle, it will search each locale in the chain. i.e. localeChain = [ "en_IN", "en_US" ]; The benifit of this is that in lower level locales you may only need to specify a small subset of the higher level properties.

Now the big question is how do I load the resource bundles into my application ??? Thankfully Flex 3 is really FLEXible in the options it gives you.

1. Compile them into the application

Using various compiler arguments, it's possible to compile the properties directly into your main application. This can be done in flex builder or with ANT FlexTasks.jar. The only annoying issue I've found with this and with other compile time options is that the Flex compiler forces you to include a copy of the framework resources for each locale that you want to compile into the app. This kind of goes against the grain of the good work introduced in the localeChain property. I'd be happy to have the framework resources only included for en_US and use locale specific bundles in my components. Using a localeChain always ending in en_US would ensure that the properties for the framework would always be accessible.

2. Compile them into resource modules

It possible to compile resources for a single locale into a resource module. Resource modules can be loaded into the resourceManager at runtime similar to mx:module. This is a handy feature if you support allot of locales and want to minimise the size of your main app. The only point I'd like to highlight in this is that it's not supported in Flex Builder or ANT FlexTasks. You have to compile them on the command line.... I know you can use the exec task in ANT, but that's no good for Linux.

3. Compile them into RSL's

You could compile your bundles into runtime shared libraries that could be included in your main app. This just saves re-compiling your bundles every time you compile the app.

4. Compile them into component modules

Our current project relies heavily on using mx:module to load components of the application at runtime. Rather than compiling the resources into separate resource modules, I think a better approach for our application would be to compile the resources for each mx:module into the module itself. This would provide good separation of dependencies with the main app. Each module can look after it's own resources.

5. Manually load them into the resourceManager at runtime

Now this approach may be a bit controversial, but it does provide some benefits. Rather than compiling the resources into the main app or into modules or whatever, it is possible to inject resource bundle objects into the resourceManager manually. Using this technique, it would be possible to use remoting to load the required resources from the server. The down side is that you'd always have to have a connection to the server retrieve the bundles and wouldn't be able to run the client in a disconnected mode during development. However, it does have the huge benefit of being able to modify the resource bundles on the server without having to re-compile / re-deploy the application.

Update: We have decided to go with option 4 for the majority of our bundles, with the exception that some dynamically created bundles will be loaded out of the database using option 5. This is for user created forms and the like.

If anyone has any opinions or suggestions please let me know. ;)