Em 25-06-2010 14:54, Norman Clarke escreveu:
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?
Sure. This has been my main complaint about Rails since I started used
it in 2007 (Rails 1). I found this message, that is probably my first
contact to Rails developers:
http://www.ruby-forum.com/topic/112538
I18n is the topic that most lacks love from Rails core team. Here are
some more examples from patches I've submited for dealing better with
internationalized applications:
http://www.mail-archive.com/[email protected]/msg10234.html
https://rails.lighthouseapp.com/projects/8994/tickets/3768-patch-add-full_message-option-to-validations
There's a long time since I last got any feedback about this ticket, for
instance (since February)...
I need to invest too many time for trying to convince the core team to
give more love to i18n issues that I've just given up. It doesn't
worth... :(
And that is the only topic I'm sad about Rails. All the remaining parts
are just perfect!
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
Sure, this would be a great feature for I18n gem. But this would be
probably better implemented like:
I18n.locale = :'pt-BR'
I18n.l(13.5, 3) # => 13,500 (for locale=pt-BR)
Currently, this yields the following error (I18n.l(13.5)):
I18n::ArgumentError: Object must be a Date, DateTime or Time object.
13.5 given.
from
/home/rodrigo/.rvm/gems/ruby-1.8.7-p...@rails3/gems/i18n-0.4.1/lib/i18n/backend/base.rb:57:in
`localize'
from
/home/rodrigo/.rvm/gems/ruby-1.8.7-p...@rails3/gems/i18n-0.4.1/lib/i18n.rb:231:in
`l'
Best regards,
Rodrigo.
--
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.
