Skip to content
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

Open
MGPalmer opened this issue Dec 18, 2017 · 8 comments
Open

Translations for date overriding main project translations #431

MGPalmer opened this issue Dec 18, 2017 · 8 comments

Comments

@MGPalmer
Copy link

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:

cormorant:~/Development/promptus/sports-mssngr [master] $ rails c
Loading development environment (Rails 4.2.10)
mssngr(dev)> I18n.t("date.formats.default", locale: :de)
=> "%d.%m.%Y"
mssngr(dev)> IceCube::Schedule.new.to_s
=> "December 18, 2017"
mssngr(dev)> I18n.t("date.formats.default", locale: :de)
=> "%d.%m.%Y"

but after switching to upstream:

cormorant:~/Development/promptus/ice_cube [master] $ git co c7b305c3f1abc98102dd28e473ecd6983b8d3bf8
Note: checking out 'c7b305c3f1abc98102dd28e473ecd6983b8d3bf8'.
HEAD is now at c7b305c... Fix core extension load order between ActiveSupport and I18n

...loading the ice cube code now clobbers our translation:

cormorant:~/Development/promptus/sports-mssngr [master] $ rails c
Loading development environment (Rails 4.2.10)
mssngr(dev)> I18n.t("date.formats.default", locale: :de)
=> "%d.%m.%Y"
mssngr(dev)> IceCube::Schedule.new.to_s
=> "December 18, 2017"
mssngr(dev)> I18n.t("date.formats.default", locale: :de)
=> "%Y-%m-%d"

(btw, "%Y-%m-%d" is also not really used in germany ;))

@seejohnrun
Copy link
Collaborator

@MGPalmer what do you think of submitting a PR to correct the date format? cc / @joelmeyerhamme

@MGPalmer
Copy link
Author

@seejohnrun Sure I can do that, but that wouldn't fix the translation-clobbering issue, right?

@MGPalmer
Copy link
Author

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"?

MGPalmer pushed a commit to Promptus/ice_cube that referenced this issue Dec 19, 2017
…ommonly set up formatting translations from the commonly used I18n systems.
@MGPalmer
Copy link
Author

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.

@avit
Copy link
Collaborator

avit commented Dec 20, 2017

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 ice_cube.date.defaults and some are top-level date.defaults so I'd like to see if we can separate that and use the actual i18n default keys.

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.

@markedmondson
Copy link

Spent Wasted a lot of time on this today before finding this, we effectively got to the same point as @avit's cleanup but the requirement of date.format.default when Rails wasn't present was painful to support.

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.

@MGPalmer
Copy link
Author

I'm not working on that project anymore, but great to see someone is picking this up :)

glaszig added a commit to glaszig/ice_cube that referenced this issue Nov 9, 2023
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
glaszig added a commit to glaszig/ice_cube that referenced this issue Nov 9, 2023
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
glaszig added a commit to glaszig/ice_cube that referenced this issue Nov 9, 2023
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
glaszig added a commit to glaszig/ice_cube that referenced this issue Nov 9, 2023
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
larskuhnt pushed a commit to Promptus/ice_cube that referenced this issue May 27, 2024
…ommonly set up formatting translations from the commonly used I18n systems.
glaszig added a commit to glaszig/ice_cube that referenced this issue May 28, 2024
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
pacso pushed a commit that referenced this issue May 30, 2024
* 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
@Faq
Copy link

Faq commented Jun 5, 2024

This still active after #546 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants