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/...) 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.
on 2014-07-28 23:00