Okay, to pre-answer your question, "why not use mx.resources?", just search this forum for "localization." I have exactly the same problem as everybody else, which is that compiling a SWF for every locale, and recompiling it for every text change, doesn't scale and doesn't perform (in terms of customer responsiveness). Adobe agrees enough that they're planning on adding runtime resource loading, I think in Flex 3, so we can skip the debate about that.
But here in Flex 2.0.1 land, I not only need to localize strings, I need to localize application-generated scalar data--in other words, dates, numbers and currency. And it doesn't look like the framework is going to let me without using the compile-time resource bundle framework. Take a look at DateFormatter. It gets its localized strings (such as "January", "Sunday", etc) from SharedResources.properties. Fair enough--good to eat your own dog food and all. But where does it store them? Why, in a private variable. In fact, near as I can tell, all of the formatter classes rely on private variables to store strings that need to be localized. This would appear to mean to me that the framework not only doesn't support, but actually actively denies, me the ability to use my own localization mechanism with the formatters. Am I wrong? Has anyone else encountered this? Come up with a solution? Or am I going to have to substantially re-implement DateFormatter, et al, for the sole purpose of assigning text to variables that I dearly wish were not private? Any assistance or insight would be greatly appreciated. Thanks, Chris
