-
Notifications
You must be signed in to change notification settings - Fork 357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translations for date overriding main project translations #431
Comments
@MGPalmer what do you think of submitting a PR to correct the date format? cc / @joelmeyerhamme |
@seejohnrun Sure I can do that, but that wouldn't fix the translation-clobbering issue, right? |
Come to think of it, why does ice_cube even need to define translation keys which match the commonly used keys from rails/ruby I18n, like "date.formats.default" etc., since there are also formatting keys scoped to "ice_cube" like "ice_cube.date.formats.default"? |
…ommonly set up formatting translations from the commonly used I18n systems.
Hah, turns out you can just remove those keys that duplicate the formatting from I18n. There weren't even in some locales. I left in the day/month names because without them some specs fail. |
Those keys come from rails-i18n so we'll need them to allow IceCube to work without Rails. It's all a bit mixed up, some are under I started some cleanup but I'm still thinking about how to best handle this. Maybe we can have a rake task to copy the keys we need from the rails-i18n locale files automatically instead of trying to keep them synchronized. |
Ended up with a Railtie which tosses the IceCube translations before Rails-i18n if it's present. Slightly imperfect but good enough for our needs. |
I'm not working on that project anymore, but great to see someone is picking this up :) |
ice_cube would inject its locale files at the end of I18n.load_path due to its I18n module being autoloaded and thereby overwrite any customisation the user may have made in other locale files earlier in the laod path. i fix this by injecting ice cube locales at gem load time so that the user has a chance to modify locale keys. 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 ice-cube-ruby#489, ice-cube-ruby#432, ice-cube-ruby#431
ice_cube would inject its locale files at the end of `I18n.load_path` due to its `IceCube::I18n` module being `autoload`ed 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 ice-cube-ruby#489, ice-cube-ruby#432, ice-cube-ruby#431
ice_cube would inject its locale files at the end of `I18n.load_path` due to its `IceCube::I18n` module being `autoload`ed 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 ice-cube-ruby#489, ice-cube-ruby#432, ice-cube-ruby#431
ice_cube would inject its locale files at the end of `I18n.load_path` due to its `IceCube::I18n` module being `autoload`ed 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 ice-cube-ruby#489, ice-cube-ruby#432, ice-cube-ruby#431
…ommonly set up formatting translations from the commonly used I18n systems.
ice_cube would inject its locale files at the end of `I18n.load_path` due to its `IceCube::I18n` module being `autoload`ed 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 ice-cube-ruby#489, ice-cube-ruby#432, ice-cube-ruby#431
* 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 `autoload`ed 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 * use __dir__ expansion instead of __FILE__ * disable linter for I18n gymnastics
This still active after #546 ? |
Hi!
I've been lagging behind the ice_cube master for a while now, and while checking out the last changes, I noticed some of our date/time display was off. I tracked it down to one commit, I think: c7b305c
Let me try to illustrate:
This is a Rails app with the ice_cube gem loaded via a Gemfile, but with a local bundler override so it uses my local repo of ice_cube. With my very old master (at d8614f7) , the default date translation looks like this:
but after switching to upstream:
...loading the ice cube code now clobbers our translation:
(btw, "%Y-%m-%d" is also not really used in germany ;))
The text was updated successfully, but these errors were encountered: