Adding optional fallback to root language bundle

[tstibbs]

I understand the fact that CAL10n doesn’t fall back to a ‘root’ language in the same way that java resource bundles do, and I understand that this was done for reasons of ‘least surprise’. However, I’d like to add the option of a fall-back. I’d like to use CAL10n, but without this feature, using CAL10n on my project is tricky. Therefore, I have implemented a change to allow a fall-back. I have tried to ensure it has the least impact on other developers or people currently using the library. So, if it looks a bit hacky (and it probably is) it’s because I’m trying to make the least changes possible.

Projects using CAL10n which wish to set this fall-back have to call Settings.setRootLanguageFallbackEnabled(true); before loading any bundles. Projects who want to use CAL10n in the traditional way need to do nothing.

The reason I would like this change is that the distribution of language packs is done totally separately to the building of my product. Therefore, at compile time there’s only likely to be one set of language files in the product (English). This means that if someone deploys the product on a system with a different locale, they need a new language pack. It would be far easier if the language files I provided were for a ‘root’ language, which could be fallen back to. This means that (for example) if a customer moved our application from a data centre in Germany to a data centre in Thailand, it doesn’t matter what the locale settings for those environments are, the application will still run and will still have logging (currently CAL10n throws an exception if the language files cannot be found, and thus there is no logging). English might be not the ideal language here, but it’s better than the app simply not running or not having any logging.