Skip to content


Adding locales to the the load path affects I18n.available_locales #20

klobuczek opened this Issue · 6 comments

7 participants


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.


Codegram member

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.

@oriolgual oriolgual closed this in fa63965

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.


I aggree with @dolzenko and #44: I think this commit should be reverted since Rails now handles i18n fallbacks (

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 is, the gem doesn't work out of the box.


+1 to reverse this



Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.