On Fri, Jun 25, 2010 at 17:15, Rodrigo Rosenfeld Rosas
<[email protected]> wrote:
> Em 25-06-2010 17:06, Norman Clarke escreveu:
>>>
>>> Do you have any real use case where it would make sense to use
>>> I18n.to_f(number, locale) instead of I18n.l(number, precision)?
>>>
>>
>> Ok, either I don't understand something, am not communicating clearly,
>> or both. I think they are opposites. This is what I think they could
>> do:
>>
>> # Given an instance of Float, format it to a string to display to
>> # Brazilian users.
>> I18n.localize(100000.01, :locale => :'pt-BR') #=> "100.000,01"
>>
>> # Given input from a Brazilian user, cast to a Float.
>> I18n.to_f("100.001", :locale => :'pt-BR') #=> 100001.00
>>
>> # Given an instance of Float, format it to a string to display to
>> # USA users.
>> I18n.localize(100000.01, :locale => :'en-US') #=> "100,000.01"
>>
>> # Given input from a USA user, cast to a Float. Notice the value
>> # is different from what a Brazilian user would mean.
>> I18n.to_f("100.001", :locale => :'en-US') #=> 100.001
>>
>>
>
> Ok, you're right, sorry, I didn't get it at first. Than, I would say that
> to_f should be implemented as:
>
> def I18n.to_f(value, locale=nil)
> locale ||= I18n.locale # current locale if none was given
> end
>
> This would allow I18n.to_f('19.250,30') == 19250.3 == I18n.to_f('19,250.30',
> :en)
>
> Why passing an option as the second parameter. What other options can you
> think of?
No other options occur to me; I would implement it similarly to the
other top-level methods in i18n. Maybe something like:
def to_f(object, options = {})
return object.to_f unless locale.separator && locale.delimiter
locale = options.delete(:locale) || config.locale
object.to_s.gsub(locale.separator_char,
'').gsub(locale.delimiter_char, '.').to_f
end
Thinking about it some more though, the problem is, "delimiter" and
"separator" are not defined by default, I'm assuming because the i18n
library doesn't want to hard-code any assumptions about what goes into
the localization files. So I'm not 100% sure this should actually go
into i18n, it may be best added somewhere in Rails. I definitely think
this is a problem that should be solved, but giving it some more
thought, I'm not sure this is the right way to do it.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
