Hi there,
I've only been following your project for a week or so now but it got
me really excited because it fixed some of my everyday problems of
using Rails in a German speaking country.
If you're watching Rails on GitHub you probably also saw my pretty
massive patch that was merged into Edge yesterday:
http://github.com/rails/rails/commit/fea7771d2294bd810d04c03c125ceac5d6bb9806.
It basically makes *all* NumberHelper methods are localized. Before
the patch this was only the case for number_to_currency.
Anyway, yesterday I wanted to start on implementing l10n support in
the Date and Time classes. The groundwork was laid (i.e. the locales
are there) but it seems that you either accidentally or by intention
left out the implementation for localizing the date and time formats.
The problem with the current implementation of localize is that it
makes it really hard to localize formats while keeping the old
functionality in Rails. To say it more clearly: It's hard to make the
tests pass. This is because the localize method treats formats that it
can't find as if the were strftime compatible strings. You even have a
comment there that reads: # TODO raise exception unless format found?
Instead of copying the stuff here, check out this gist if you want to
know the way I'd love to implement it:
http://gist.github.com/3351
To make this work it'd be great to have a small change in the way
SimpleBackend#localize currently works. I would like it to have a
different behavior for the format parameter - it should act
differently for symbols and strings. This would still be true to the
rest of the API since the default method has a similar approach.
Basically something like the second file in the gist:
http://gist.github.com/3351
First of all, this cleans up the API and makes it more evident that
the method is really doing two totally different things for different
types of parameters.
Second, it's IMO more logical. A symbol denotes a format (or, in Ruby
speak, a key in a hash) whereas a string is interpreted as a strftime
string.
Lastly and most importantly, it makes it easier for other people to
use your library because it raises an exception when an undefined
format is passed so that the application/framework that uses the
library can decide on how it handles this. You could even go a step
further and add an else statement to the case-when that raises
something like a I18n::InvalidFormat exception.
The concrete advantage for Rails (and for others that use your
library) is evident if you look at the other files in the gist. With
the current implementation I need to do a lookup first and only call
localize if I can pass it an existing format because due to the
current implementation in Rails I can't use your strftime fallback.
Plus, strftime(:non_existent) wouldn't produce sensible output anyway.
Another option would probably be to support a :default option for
localize as translate does. But to be honest, I don't think this would
be a really good solution because as I said earlier, a library should
IMO delegate as much error handling as possible to the client that
uses it (in this case Rails).
I'm putting this up for discussion but I think it would be a really
big step in the right direction. If you decide that the points I make
are valid, please make sure that you integrate them ASAP. I'd really
like to avoid rolling out Rails' next feature release with some half-
assed and unfinished i10n. ;-)
Looking forward to hearing your comments.
- Clemens