Thanks for the info Gordon. I can appreciate the effort required to localize to other languages. Like you said, it would be great to have the community generate "language" packs and share them with others.
Can I clarify one thing though - let's say I had localized en_US to es_ES myself. I specify locale=es_ES,en_US as a compiler arg in FB3 and it creates as output files myapp.swf and es_ES.swf. The later of which is much smaller in size which I'm assuming is because it just contains the es_ES resources, not a full copy of the application code. If this is the case, what is the logic that determines when this es_ES.swf file is loaded? Would it always load it, or only load it when I explicity set the localeChain to include es_ES? Ryan --- In [email protected], "Gordon Smith" <[EMAIL PROTECTED]> wrote: > > Due to time and resource constraints, Flex 3 will localize the framework > classes only for English and Japanese. I hope that we can support more > locales in the next release, and that the community will help us with > this task once the SDK is open-source. > > Gordon Smith > Adobe Flex SDK Team > > ________________________________ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of rmarples > Sent: Tuesday, January 08, 2008 4:10 PM > To: [email protected] > Subject: [flexcoders] Non en_US locale's number/date format strings > > > > We are building an application that has a requirement such that numbers, > currency and dates need to be formatted based on the user's locale. eg: > 1,500.23 in english is 1.500,23 in german. My understanding is that Flex > does not provide the ability to automatically read these format styles > from the operating system and instead reads them from the framework's > built-in .properties files. The question I have is, is Adobe planning on > delivering any more resource bundles other than english out of the box? > It occurs to me that things like number and date formats are IEEE > standards and thus it seems silly for us to have to re-create them with > the risk that we might make an error. > > Ryan >
