I have been working with Adobe Flex for about a year now and am very much a Flex advocate. However the support in Flex for localization/internationalization is a constant nagging disappointment that makes developing international rich web applications a miserable experience!
The fundamental deficiencies include:
UI Controls Are Not Localization Aware
What I mean is that to render localized text for each control you must include either a compiler directive or run-time code for each property where you want a localized string.
In this example the compiler directive @Resource() is used to define the resource string for the text property:
<mx:Label text="@Resource(bundle='myResources', key='text')"/>
To support dynamic locale changes, a runtime binding expression accessing the ResourceManager class is used instead of the compiler directive: property:
<mx:Label text="{resourceManager.getString('myResources', 'text')}"/>
So the two implementations above are perfectly functional, but very cumbersome to implement when localizing an entire web application.
… So there has to be a better way ...
Why not embed the resource localization logic directly into each UIComponent and expose resourceName nad resourceBundle as design time properties?
Well, that exactly what I did! I created wrapper controls derived from the mx controls that add the resourceBundle and resourceName design time properties.
See the screenshot here where these properties are accessible in the FlexBuilder designer – control properties tool window.
With this concept (borrowed from ASP.NET) a resource string naming convention is also needed to actually provide localized strings for each string property of the control. For example with a Label control you may want to provide localized strings for the Label.text property and Label.toolTip property. Since this implementation only exposes a single resourceName property for the control I adopted a convention that allows me to defined the resource strings in the resource property files with a dot property name appended to the control resourceName.
myLabel.text=This is the label text
myLabel.toolTip=This is the label toolTip
Note, the resource strings above are named with the control’s resourceName and then have “.text” and “.toolTip” appended. This convention enables me to define a single resourceName on each control and gives me the flexibility to define multiple resource strings for the individual control properties. This convention I have outlined greatly simplifies the localization coding burden on the Flex developer! I don’t have this implemented, but if instead of requiring the entry of the resourceBundle property, if it were left empty it would be nice to inherit the resource bundle defined for the MXML file that contained the control.
<mx:Metadata>
[ResourceBundle("myResources")]
</mx:Metadata>
I’m sure there are other ways to tackle this problem and simplify the burden on the Flex developer, my main point here is that we need something build in to the Flex framework to handle much of the nasty work for us.
Flex Framework Resources are only distributed in English
Flex 3.x Framework Resource Property Files
Flex includes a number of framework resource bundles that support the mx controls and all other framework generated strings. However, Adobe only provides these bundles in English! That means when you want to create a Flex application in another language you are responsible for generating localized versions of of all these resource files! This is a serious kick in the teeth as a Flex developer. These resource files include more than just simple strings to localized, but they include all the date/time and numerical formatting information.
Once you resign yourself to the fact that you are on your own and you have to localized all these resources, the next thing you find out is that these files are a mess, there is very little organization or consistency.
Here is an example, all of these resources are defined in the SharedResources.properties file.
# DayNames Long (DateBase, DateChooser, DateField, CalendarLayout)
dayNames=Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday
# MonthNames Long (DateBase, DateChooser, DateField, CalendarLayout)
# appended with monthSymbol
monthNames=January,February,March,April,May,June,July,August,September,October,November,December
# Common symbols (DateFormatter, DateValidator, DateField)
dateFormat=MM/DD/YYYY
monthSymbol=
So far so good, but then you will find the following properties in the formatters.properties file.
am=AM
pm=PM
dayNamesShort=Sun,Mon,Tue,Wed,Thu,Fri,Sat
# appended with monthSymbol in SharedResources
monthNamesShort=Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec
So why are very similar resource strings such as month naming and day naming split across multiple resource files. I understand why Adobe placed these resources where they did because they grouped them based on the namespaces where they are being consumed. But this just wreaks of either laziness or lack of forward growth planning. So if I want to use the short day name in a calendar type of control I have to resolve it from the formatters resource bundle … see what I mean?
No built-in support for run-time editable resource property files
The standard convention in Flex is to compile all resource bundle property files into SWFs. Functionally this works great and is highly efficient, however in the real world many times we are required to provide runtime editable resource files, meaning that they can’t be compiled into the application and must be editable in a text or XML file distributed with the application. This convention allows locales to be added and edited in the field. Many times a single resource string my have been incorrectly localized or a customer may require the text to be altered in some minor way. Editable resource property files can realize this requirement.
Flex does provide very nice low-level programmatic access to create and alter resource bundles at run-time. There is a great article on Runtime Localization written by Gordon Smith located at Adobe Labs on the subject. >>> LINK
However it would be very nice if the build-in ResourceManager could resolve and load raw resource property files hosted on the web server.
For my needs, I created XML resource property files and wrote the management code to load the proper resource files from the web server, parse the XML and dynamically create the resource bundles based on the selected locale chain.
No support for timezones
I don’t need to go into any great depth on the limited abilities of Flex and Date/Time, there are many articles out on the web on this subject. Basically Flex has no concept of timezones built into the framework. This make it particularly challenging for any time conversions especially across historical daylight saving time rules. I read somewhere that there were plans in Flex 4.0 for timezone support, let’s keep our fingers crossed.
