ice_cube
ice_cube copied to clipboard
fix I18n.load_path injection
ice_cube would inject its locale files at the end of I18n.load_path due to its IceCube::I18n module being autoloaded and thereby overwrite any customisation the user may have made in other locale files earlier in the load path.
i fix this by injecting ice cube locales at gem load time so that the user has a chance to modify locale keys later.
this also eliminates a bunch of delegation having a custom I18n module; IceCube::I18n is just the same as ::I18n if the i18n gem is available.
resolves #489, #432, #431
since I18n.load_path is dependent on gem load order there still is a chance ice_cube's vendored translations will overwrite definitions:
Gemfile:
gem 'rails-i18n'
gem 'ice_cube'
I18n.localize requires the user define translations anyway so it's better to be a good gem and not simply break things. thus i moved all <locale>.date.* keys to be used only during tests and cleaned up a little.
in the meantime i'm using this patch in a rails app to move ice_cube's translations to the top of I18n.load_paths:
config/initializers/ice_cube.rb
module IceCube
LOCALES_PATH = I18n::LOCALES_PATH
remove_const :I18n
I18n = begin
require "i18n"
::I18n.load_path.prepend *Dir[File.join(LOCALES_PATH, "*.yml")]
::I18n
rescue LoadError
NullI18n
end
end
?
This was breaking my app also. I was wondering why I18n.localize was using a different rendering for times, when i used in a view Schedule.to_s. The patch you showed here, fixed it:
in the meantime i'm using this patch in a rails app to move ice_cube's translations to the top of
I18n.load_paths:
config/initializers/ice_cube.rbmodule IceCube LOCALES_PATH = I18n::LOCALES_PATH remove_const :I18n I18n = begin require "i18n" ::I18n.load_path.prepend *Dir[File.join(LOCALES_PATH, "*.yml")] ::I18n rescue LoadError NullI18n end end
Thanks.
Using ice-cube germ breaks our app and the mentioned workaround fixed it. This PR should be merged!
By removing the non-ice_cube date translations and loading them only in the tests, I think that would break things like this and this
i have 2 ideas:
- have an ice_cube namespace as fallback:
I18n.t("day_names", scope: %i(date ice_cube))[day] - raise on missing translation:
I18n.t!("date.day_names")[day]
I assume the reason it's done this way is so that if ActiveSupport is available, it'll load the translations for day_names and month_names from there instead, rather than "duplicating" it. However, we're duplicating it anyway.
Why not just move those translations into the ice_cube namespace, and then you can remove those includes from the tests completely? We also don't ever use the abbr_day_names or abbr_month_names, so I'm not sure why we include translations for them?
OK - having had a poke about, we cannot remove the date.day_names etc from the translation files. These are used by the localisation calls (I18n.l) such as here.
Please revert the changes to the locale files, and remove the added locales from the spec directory, and see if everything tests ok. Without doing this, the gem would be broken for anybody using it in an environment without ActiveSupport.