Forum: Rails I18n #localize for numbers

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
5976001c9ebf095c4988855a4e102de5?d=identicon&s=25 Clemens Kofler (Guest)
on 2014-07-28 21:00
(Received via mailing list)
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

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
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.
This topic is locked and can not be replied to.