On Fri, Jun 25, 2010 at 14:12, Rodrigo Rosenfeld Rosas
<[email protected]> wrote:
> This is not about easy of interpreting numbers, but about consistency and
> DRY.
>
> In my case, this is also a currency situation and although it is clear how
> to parse the string, we shouldn't be concerned about this while defining our
> models.
>
> This is something that a framework should do by its own since it is
> feasible, DRY and less error prone and I can't see any reasons for not
> supporting this on the Rails core side.
>
> For instance, consider this pseudo-code snippet that could be put in the
> numericality validator code:
>
> def parse_raw_value_as_a_number(raw_value)
> raw_value.gsub!(I18n.separator_char, '').gsub!(I18n.delimiter_char,
> '.')
> ...
> end
>
> WDYT?
Yeah, I do think making it transparent for models is a good idea. Do I
understand you correctly that Rails currently casts the numeric string
to the wrong decimal value, even if you set the i18n delimiter and
separator?
In any event I do still think a local-aware `to_f` and `to_i` could be
useful as top-level I18n methods. You may need to do locale-aware
casts outside validations, and you may need to do them for a specific
locale even though your current locale is set to something else, e.g.:
I18n.to_f("100,001", :locale => :pt_br) #=> 100.001
I18n.to_f("100,001", :locale => :en_us) #=> 100001.00
--
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.
