Try loading bundles with locales not specified in the master file

[prantlf]

Specifying all available bundles in the master file when a product is released may not be convenient. If a localization is provided afterwards, the master module has to be modified, which gets even more difficult when it is compiled to a single output file. This makes possible adding bundles just by populating their locale-specific directories - without modifying the master file, which may not be easy after the product has been deployed and the language packs work just the "unzip" way and cannot include any code performing code modifications.

If the locale is specified in the master module, no additional locale forms are tried. For example, if { "fr": true } is there and the configuration requests i18n: { locale: "fr-fr" }, the "fr-fr" bundle is not attempted to load. This makes the dynamic behaviour not affect the existing master modules with explicitly specified locales, if this change should not affect them.

Bundles are attempted to load on the first access and the success or failure are remembered by true or false in the master object; not to repeat the loading attempts later again.

[thijstriemstra]

Thanks, this is exactly what I needed, and it seems to work :) @jrburke, is this something you would consider adding?

The only thing that seems to be different from the original version is that files that don't have a translation are now throwing a 404 error, whereas the original code would silently ignore these 404s.

A workaround for that 404 problem would be using a single .js translation file, or defining enough to make it pass:

define({});