Nope, This would be the case if you wanted to add 3 different locales. If you define es_MX,es_ES,en_US this is more a locale-chain (I reverse learned this from the unit-test code.
Assuming you have 3 locale property files, en_US containing the complete set of values and only some of them being translated to spaninsh in general and only some of those having a different mexican translation, then when setting the application to es_MX, the application would use es_MX if they are provided, but fall back to es_ES if they were not and again fall back to en_US if no spanish translation at all was present. This alllows you to sort of translate the stuff you need without having to translate all the stuff Flex would complain about if it was missing. So there is in fact a great difference. Chris -----Ursprüngliche Nachricht----- Von: Frédéric THOMAS [mailto:[email protected]] Gesendet: Donnerstag, 1. November 2012 20:43 An: [email protected] Betreff: Re: AW: AW: Compiler Arguments Chris, The locales shouldn't be express like that from FM4.x ? <localesRuntime> <locale>es_MX</locale> <locale>es_ES</locale> <locale>en_US</locale> </localesRuntime> -----Message d'origine----- From: [email protected] Sent: Thursday, November 01, 2012 8:34 PM To: [email protected] Subject: AW: AW: Compiler Arguments Hi Alex, well the goal oft he project isn't to do anything "sensible" from view of the resulting SWF, but it's part of the Flexmojos Unit-Test suite. In this case the maven config is this: <build> <plugins> <plugin> <groupId>net.flexmojos.oss</groupId> <artifactId>flexmojos-maven-plugin</artifactId> <version>%{flexmojos.version}</version> <extensions>true</extensions> <configuration> <localesCompiled> <locale>en_US</locale> </localesCompiled> <localesRuntime> <locale>es_MX,es_ES,en_US</locale> </localesRuntime> </configuration> </plugin> </plugins> </build> Which should instruct the compiler to add en_US as compiled locale, and to add es_MX as runtime locale while defaulting back to es_ES or en_US if the corresponding properties are not defined in those locales. This test worked for every FDK up to 4.5.1 but fails randomly in 4.6 and 4.8. As I mentioned ... somebody doing a real project wouldn't do such a thing, but that projects sole test is to to test the compiler-configuration and it seems that we have an issue here ... unfortunately I have never ever used the commandline compiler therefore I currently don't know if this is a Flexmojos issue or a Flex-Issue that I have to build some workaround for. Chris -----Ursprüngliche Nachricht----- Von: Alex Harui [mailto:[email protected]] Gesendet: Donnerstag, 1. November 2012 19:39 An: [email protected] Betreff: Re: AW: Compiler Arguments On 11/1/12 10:33 AM, "[email protected]" <[email protected]> wrote: > Well it is used several times ... > > -metadata.language=es_MX,es_ES,en_US > -metadata.language+=en_US > > I've never touched that part of Flexmojos code and I just wanted to > know what those lines should be and what has changed before startig to > implement anything. > I have never used metadata, so I don't really know, but it looks like it should be a single string (whereas locale takes an array of strings). So I think the parser just gets fooled and thinks there is a comma separator between arguments. I saw a comment about having to guess when parsing about the end of a list. This also makes me wonder if the following line where you do += is going to work either since this isn't a list. You can try a simple app and compiling it from the command line with these options and see what works and what doesn't. Is there logic or a config that is causing the +=en_US? It seems like it would be better to concat them on one single string without duplicates and without comma as the separator. I don't know if quoting will work or not but you can try that as well. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
