Date and Time classes i18n/l10n implementation
Reported by Clemens Kofler | August 2nd, 2008 @ 05:53 PM | in 2.x
The current Edge lacks proper support for i18n/l10n in the Date/Time/DateTime/TimeWithZone classes. The definitions in the locale were there but they weren't used yet.
This patch adds the missing i18n/l10n support.
Here's a list of the changes I made:
- Removed all formats that aren't used internally by Rails from Time::DATE_FORMATS and Date::DATE_FORMATS and put them in the locale instead.
- Renamed DATE_FORMATS to DEFAULT_FORMATS because it seems more fitting.
- Restructured locale to match the hierarchical style I introduced for the localized NumberHelper (see this ticket.
- Fixed formats in locale since they weren't using Rails' default formats. Also fixed the tests that failed because of this change.
- Slightly changed the implementation of how Procs can be used as formats to make them i18n/l10n compatible. Instead of lambda { |time| time.strftime("%B #{time.day.ordinalize}, %Y %H:%M") } one should now use lambda { |time| "%B #{time.day.ordinalize}, %Y %H:%M" }. The old style should work 99% of the time - the only exception should be if %% is used in the formatting string since it would be evaluated twice.
- Added implementation tests.
- Updated documentation to explain how to add formats.
- Added deprecation warnings as singleton methods for DATE_FORMATS constants.
What probably needs to be done is update the tests for custom date formats to use the locale instead of the DATE_FORMATS constant. But I don't really like touching existing (stable) tests so I didn't include the change in the patch.
Feedback, as usual, is very much appreciated.
Comments and changes to this ticket
-
Geoff Buesing August 3rd, 2008 @ 02:37 PM
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 August 3rd, 2008 @ 06:40 PM
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 August 3rd, 2008 @ 06:54 PM
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 August 3rd, 2008 @ 07:42 PM
- no changes were found...
-
Clemens Kofler August 3rd, 2008 @ 09:38 PM
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 August 3rd, 2008 @ 10:50 PM
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 August 3rd, 2008 @ 10:54 PM
- → State changed from “new” to “open”
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Source available from github
The Git repository resides at http://github.com/rails
Check out the current development trunk (Edge Rails) with:
git clone git://github.com/rails/rails.git
Creating or reviewing a patch
See the contributor guide.
Creating a feature request
Please don't. If you want a new feature in Rails, you'll have to pull up your sleeves and get busy yourself. Or convince someone else to do it. See the contributor guide on how to get going. But posting them here is just going to lead to ticket root.
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.
Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".
Yaroslav Markin