{5} Assigned, Active Tickets by Owner (Full Description) (3 matches)

Currently Globalize only supports a fallback to the base language if a translation does not exist. However, if one exploits Globalize's ability to have locale-specific languages, such as en-US and en-GB, then the more appropriate fallback to the "root" language (en, in this example) is called for.

I propose that if a translation for a locale-specific language is not available, then Globalize should substitute the "root" language translation. Example, with base_language = fr:

fr: "La couleur du camion etait rouge."
en: "The colour of the lorry was red."
en-US: "The color of the truck was red."
en-GB: nil
en-AU: nil

When searching for the en-GB or en-AU translation of the text "The color of the truck was red.", Globalize should return "The colour of the lorry was red." and not "La couleur du camion etait rouge." Keep in mind that 90% of the translations within a language family would be identical -but getting that last 10% right can make a world of difference between a foreign-feeling app and a truly localized one.

Ideally, there should be an explicit relationship between the root language en and the locale-specific languages en-US, en-GB and en-AU. In the absence of any DB schema support, parsing the language code for the string before the dash ("-") would suffice to find the root language.

Without this support, Globalize will require a huge amount of duplicated translations to support some of the most widely spoken language families on the planet:

en is a base for en-US, en-GB, en-CA, en-AU, en-NZ, en-BZ, etc. es is a base for es-ES, es-MX, es-CO, etc. fr is a base for fr-FR, fr-CA, fr-CH, etc. pt is a base for pt-PT, pt-BR, etc.

Just with those four root languages, you have probably covered well over a billion native speakers.