The line below breaks the behavior of I18n.available_locales:
I18n.load_path += Dir[File.expand_path(File.join(File.dirname(FILE), '../locales', '*.yml')).to_s]
That is undesired behavior as some application dynamically figure out the available locales. Providing translations for DateValidator doesn't mean that the rest of the application is translated. None of the common gems are that intrusive and they provide at most english translation.
You can provide the locale files in the gem but do not load them all.
Agree. @klobuczek any thoughts on what would be the best way to make this less intrusive?
I think idea here is to actually not load any translations at all because Rails thinks it supports languages it doesn't support.
If a new translation is needed, then developer should pull it from repo or gem and merge into his/hers translation file.
Don't autoload all locale files. Closes #20
Can somebody clarify why autoloading en locale was removed? It leads to issues like #44 and makes people copy translations into their own locale files. Checking other gems suggests loading en locale by default is perfectly fine, e.g. https://github.com/mislav/will_paginate/blob/master/lib/will_paginate/railtie.rb#L35
I aggree with @dolzenko and #44: I think this commit should be reverted since Rails now handles i18n fallbacks (https://github.com/svenfuchs/i18n/wiki/Fallbacks#custom-fallback-rules).
If a translation isn't available in a locale, Rails will fallback to another one.
Another solution would be to only autoload (or provide) en locale file, which would be a little more reliable than importing locale files in the app, which isn't DRY at all.
Rails itself autoloads en translations...as is, the gem doesn't work out of the box.
+1 to reverse this