Em 25-06-2010 17:30, Norman Clarke escreveu:
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
Actually, the order does not seem to be right. Maybe you mean:
def to_f(object, options = {})
locale = options.delete(:locale) || config.locale
return object.to_f unless locale.separator&& locale.delimiter
...
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.
I warned you it was a pseudo-code. delimiter_char and separator_char are
not defined in I18n but it made my example clearer. Actual code would be
something like:
def I18n.delimiter_char
t('number.format.delimiter', :default => nil)
end
--
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.
