We're working on a site that needs the Latin alphabet version of the Serbian locale (scr). This locale, together with a number of other ISO-639-2 locales have been moved to a different directory 4 months ago (See: 4fb32b9).
Unfortunately, this means that the locale is never loaded, the pattern generated during initialisation only loads files that are in the root of the locale directory.
There are 2 solutions for this problem:
I'm willing to provide a pull request, but I'd like to know the direction I should choose as I do not know the reason these locales are in their special directory in the first place.
Those locales were moved out because the current validations don't support the ISO-639-2 scheme or the script subtag.
Implementing the script subtag (defined by ISO 15924) in the https://github.com/tigrish/iso repo would be the thing to do before moving scr back into the locale directory. And bonus, it would be renamed to sr-Latn too.
Are you talking about ActiveModel validations, or about these validations?
1.9.3-p286-falcon :015 > ISO::Tag.new('sr').valid?
1.9.3-p286-falcon :014 > ISO::Tag.new('sr-Latn').valid?
1.9.3-p286-falcon :016 > ISO::Tag.new('scr').valid?
I can't seem to find the code in this gem that hooks rails-i18n, only in i18n-spec. Is this change in the iso gem only needed so the specs will pass, or does it actually break stuff in real applications? If it doesn't break anything, I can monkeypatch the load path in my own application.
In the mean time, may I suggest that you remove the ISO-639-2 locales from the README's available locale section? I can try to add the desired functionality to the iso gem, but I have no experience with that so it will take some time.
Yep, you've found the right validations, you'd want ISO::Tag.new('sr-Latn').valid? to return true.
A quick and dirty workaround is to include the subdirectory in the locale name when defining the app's available locales. Example:
# in application.rb
config.i18n.available_locales = ["iso-639-2/gsw-CH"] # HACK
config.i18n.default_locale = "gsw-CH"
It'd be nice to support the broader set of ISO639-2 codes http://www.loc.gov/standards/iso639-2/php/English_list.php
@paddor your solution only works if you are not using the available locales form something else. It is not compatible with i18n_routing for example.