Hey guys,
it's been a while since I've been active on this list. ;-)
There's something that's been bothering me for ages and I'm finally
ready to do something about it: That something is the localization of
numbers.
If you think about it, two of the main simple things that you need to
localize in your international app are dates/times and numbers (leaving
out more complex things like different address formats and whatnot).
i18n has been doing the former pretty much since the beginning (at least
as far as I remember) but the latter is still done in Rails itself,
using the NumberHelper. I propose to change this and handle number
localization in i18n itself.
Here's an API that *could* work (based on the default de.yml):
# dates and times
I18n.localize(Date.civil(2014, 7, 28)) # => works as before
I18n.localize(Time.local(2014, 7, 28, 20, 30, 0)) # => works as before
# currency formatting
I18n.localize(19.90, as: :currency) # => 19,90 €
I18n.localize(19.90, as: :currency, format: '%u %n') # => € 19,90
# percentage formatting
I18n.localize(33.3333, as: :percentage) # => 33,33%
I18n.localize(33.3333, as: :percentage, format: '%n %') # => 33,33 %
# all other numbers
I18n.localize(33.3333) # => 33,33
I'm differentiating between these 3 types of numbers because these are
the ones defined in the CLDR.
IMO this would be a change with relatively low impact to the existing
code base:
- The ArgumentError for I18n#localize
(https://github.com/svenfuchs/i18n/blob/master/lib/i18n/backend/base.rb#L53)
needs to be adapted to accept both numbers and dates/times.
- Date/time formatting should be extracted into a separate method or
(better) class (DateTimeLocalizer?).
- Number formatting needs to be added (again: separate method or class).
Existing discussion points would be which Rails options to include
directly in i18n:
- precision
- separator and delimiter
- strip_insignificant_zeros
I'd definitely say yes to precision as well as separator/delimiter but
I'm not sure about the zeros.
Rails' NumberHelper could then leverage these helpers where it can and
keep its other helpers (human formatting as well as phone numbers) as
desired. And it needs to make that whatever it passes to i18n is
actually a number.
What do you think? Should I fork and make a spike?
- C.
--
You received this message because you are subscribed to the Google Groups
"rails-i18n" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rails-i18n.
For more options, visit https://groups.google.com/d/optout.
