This project is archived and is in readonly mode.
Date and Time classes i18n/l10n implementation
-
Geoff Buesing
Building localization into Date/Time classes is a cool idea, but it seems to be a step ahead of the existing i18n/l10n strategy, which requires that you pass objects into locale-aware helpers, like so:
i18n.l time, :format => :longOr am I missing something?
-
Clemens Kofler
While I agree that this is a possibility, I think it would be inconsistent with the i18n/l10n stuff that has made it into core so far.
Pretty much everything till now has been a drop-in replacement: If I use number_to_currency, I can now remove any hacks that I used before (no more number_to_currency_with_euro and alias_method_chaining it). Same goes for ActiveRecord error messages, for example.
Now if we don't localize date and time formatting, people have to use localization the way you wrote it: i18n.l(time, :format => :long). The Rails standard way to format dates, however, is time.to_s(:long). IMO it's quite obvious that this is inconsistent.
While I'm perfectly aware that this is a bigger change than, say, the number helper methods, I think it's really important to not stop the localization efforts halfway through. I know that localized pluralization is still missing (and probably will stay that way for some time since it's a very complex topic), personally I don't see any reason to not include something that is quite simple and is backwards compatible (apart from the slight change in behavior for procs that I mentioned).
We can discuss this further on the mailing list or in IRC if you think this is necessary.
-
Sven Fuchs
Although I agree think that this should eventually go into core, I don't think that this is a good situation. We should follow the strategy "implement as plugins - review, discuss, extract - suggest core patches" for another dev cycle for everything that not definitely needs to go into core right now (like necessary api changes, bug fixes). This strategy prooved extremely valuable in the past and we should stick to it for now even if patches will become more "obvious" over time.
I've talked this over with Clemens on IRC and he agreed to contribute his code as a plugin, which I think is the way to go.
-
Clemens Kofler
And here it is: http://github.com/clemens/locali.... ;-)
So Geoff, if you really don't want to include this into core, this ticket can be closed.
-
Geoff Buesing
Let's leave this open -- I like the idea of #to_s being locale-aware, but I agree with Sven's approach of testing this out in a plugin first.
-
Geoff Buesing
- State changed from new to open
-
josh
This ticket is over 3 months old. Any updates?
-
Clemens Kofler
The plugin is still available and I've received some feedback of people who liked it. If you want it included in the core and like me to come up with a fresh patch to the current edge, I'm more than happy to do it - just let me know!
-
Yaroslav Markin
Plugin is really nice but I'd say stuff like this needs to be implemented in I18n itself, not on top of Rails.
-
Geoff Buesing
@Sven, what are your current thoughts on this -- should this be considered for 3.0, or is this best left as a plugin?
-
Clemens Kofler
Geoff, I talked to Sven today about this. We'll have a closer look at this and then let you know what we think about it.
-
Sven Fuchs
Geoff, Clemens and I have talked this over and we think the proposed patch does a bit too much. Also, we agree with Yaroslav that some of this should be solved in I18n instead of Rails.
We'll look into this next week and come up with separate patches for I18n and ActiveSupport.
So, I guess you can close this ticket and we'll open a new, more focussed one then.
