Changes between Initial Version and Version 7 of Ticket #15260

May 1, 2012, 4:58:13 PM (9 years ago)
Karl Tiedt

Replying to rcgill:

Replying to ktiedt:

I guess we are unclear what i18n path we are getting taken down then -- how do you ensure you get "non legacy i18n"?

My explanation at comment 3, though accurate, was somewhat incomplete/misleading. The bottom line is that the builder automatically converts legacy bundles to AMD. So if you delete localized files from the output and then try to load any of the deleted locales, the program will fail to load. That is normal, correct behavior.

Again, if you want to output a build with fewer locales than are in the source root, then the solution is to delete those locales from that source root. To my knowledge this was not a legacy option. It is currently not an option with the new builder and doesn't seem that generally useful. The problem could be easily solved by writing a custom transform to go before the writeAmd transform. Of course that's a fairly advanced option and we don't have good docs on how to do that yet. Please confirm this is your issue and I'll try to help out with that transform.

As mentioned in comment 3, none of this applies to flattened bundles. For those, you will get exactly what you ask for with more, no less.


  • Ticket #15260

    • Property Cc Patrick Ruzand added
    • Property Priority changed from undecided to low
    • Property Status changed from new to assigned
    • Property Milestone changed from tbd to 1.8
  • Ticket #15260 – Description

    initial v7  
    77We also still cannot find a way to get i18n.js to load from our layer (its required to be left on our server despite being in our built files)
     9By "delete from source root" you mean modify the NLS file's definition of locales supported?
     11Ultimately what we are trying to do (and this is how it worked in 1.6) is if a module supports "wx-yz" and we do not... we want "wx-yz" to fall back to "root" - How we achieved this in 1.6 was we deleted the CLDR folder because that 1+Mb of NLS entries for many locales that we never supported were not needed. The flattened builds took care of anything we did support.
     13However, (and you may have fixed this with one of your latest check-ins) it 1.7.x this behavior would kill the loading process and hang on the 404's for the CLDR nls files. And the reason this happened would be because a generic locale was hit that a CLDR module supported "zh" or "en" but our flattened bundles were "zh-cn" or "us-en" so the loader would try to pull in an "en" only flattened bundle.
     16If that still sounds like what the Transform would be a good fit for... I am certainly interested in hearing more :)