Gordon, thank you! I shouldn't have stopped looking when I got to the default date format string (which is loaded into a private variable in DateFormatter). This perfectly solves my problem.
(And you forgot to say, "Yes, you're wrong.") Thanks, Chris --- In [EMAIL PROTECTED], "Gordon Smith" <[EMAIL PROTECTED]> wrote: > > The framework loads the localized day and month names from the resources > into properties of the DateBase class, but lets you change them. > > Try setting DateBase.dayNamesShort, DateBase.dayNamesLong, > DateBase.monthNamesShort, or DateBase.monthNamesLong before calling the > format() method of your DateFormatter. > > - Gordon > > ________________________________ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Chris Luebcke > Sent: Wednesday, April 11, 2007 2:16 PM > To: [EMAIL PROTECTED] > Subject: [flexcoders] Localizing formatters without mx.resources > > > > 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 >
