#localize for numbers

Hey guys,

it’s been a while since I’ve been active on this list. :wink:

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:

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.