Uploaded image for project: 'Apache Flex'
  1. Apache Flex
  2. FLEX-15343

ResourceManager localeChain not respected, influenced by order of compiler options

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Not A Problem
    • Adobe Flex SDK 3.0 (Release)
    • None
    • i18n : Bundle Support
    • None
    • Affected OS(s): Windows
      Affected OS(s): Windows XP
      Browser: Internet Explorer 7.x
      Language Found: English

    Description

      We have an application with many locales. We used the copylocale tool found in the sdk to generate new locales. Some of these locales are connected to a country eg. fr_BE, pt_PT.
      In addition we have a number of locales that are shared by some of these country locales. eg. We introduced fr, which is used by all french variants: fr_BE, fr_FR, fr_CH, ....

      The idea is that by using the localechain we would have a fallback mechanism similar to the one in java. When selecting a certain french variant, we set the correct chain for that variant. [fr_BE, fr, en_US], [fr_CH, fr, en_US], ....

      This allows dynamic switching of locales and sharing as many properties as possible.

      The problem I found is that when setting this locale chain explicitly, values are returned by the resourceManager that are not even part of the current chain. The order of handing locales to the compiler options plays a big role here, changing the order gives different effects.

      Since it is not completely trivial to reproduce, I attach a minimal flexbuilder 3 project that demonstrates this issue. Im currently looking for a workaround if any.

      Steps to reproduce:
      1. Unzip the attachment and open the project in flex builder
      2. Run the project and select different locales with the combobox. Especially look at the nl_NL locale, the displayed values are taken from the completely unrelated pt_PT locale.

      In addition change the order of the locales handed to the compiler, especially put a different locale as the last but not least, keeping nl_NL as the last one. it will now fallback to a different unrelated locale.

      This issue is very serious for us, as we are developing for multiple locales simultaenously. Also, as I said, I put a lot of effort into getting this sample as minimal as possible. In our actual application we have about 20 locales which complexifies this issue a lot.

      Attachments

        Activity

          People

            adobejira Adobe JIRA
            adobejira Adobe JIRA
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: