Forum: Ruby on Rails Rails and localization

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
1a1551a3a11e750cd46e5699cb175941?d=identicon&s=25 Rodrigo Rosenfeld Rosas (Guest)
on 2007-06-20 19:40
(Received via mailing list)
I've started to learn Rails about a month ago.

It seems wonderful, except for one major issue: localization!

It's too complicated to develop a serious application in Brazil with
(or whatever other country with localization rules different from

I mean, how can I validate a number from user's input such as 1.234,45
how can I show it in all views in the same format, although storing it
correctly in database and doing math operations correctly... I used to
develop web sites in Perl a long time ago. It was pretty simple to add
localization support.

In Rails, it seems I would need to use something like number.l, at best,
my views... Maybe override String#to_f method could make "number
= '1.234,45'.to_f" be
converted to 1234.45, but I'm not that familiar with Ruby already...
how about the oposite? How to do that snippet show correctly?

<%= @project.price %>

I would like '1.234,45' output instead of '1234.45'.

It seems I would need something like

<%= @project.price.l %>

at least (and implement Class#l, of course).

Not to say that I would need to create a plugin for overriding the
validates_numericality_of helper. Or, maybe, overriding String#to_f, it
wouldn't be necessary...

That said, IMHO, as Rails claims to follow the 80/20 rule, it should
consider a good suport for basic things like this kind of basic
localization, such as numbers, currency and other charsets, or at least,
good support to utf-8. I understand it is more a problem of Ruby than
Rails, but I think that there should be a huge effort to achieve
localization as easy as with Perl, Python and so on... Unless, most of
world will not be satisfied with Rails for serious applications, unless
they need to write only English sites...

More than 50% of the sites in the world are monolanguage in a language
than English. So, it should be considered in Ruby/Rails to give a better
support for these applications, for continue claiming their solution is

Maybe, the better approach would be embedding this support directly in
Ruby language, but I think the Rails users should help on this...

I've looked at Globalize, GLoc and some other plugins. These two are for
internationalization, which is not a requirement for most of these
language than English" applications. They usually just need:
 - localization of numbers and currency
 - support for other charsets, or at least utf-8 (or 16)
 - translation of Rails messages, or, at least, the validation error
messages. I know there are some dirty methods to do that, but I think
should be embedded directly on Rails with language directories
all translated error messages and scaffolding.

Another good topic is scaffolding... I think it should be more flexive.
instance, it should be possible for a project having, as an example,
an 'scaffolding' directory   that should be used instead of the default
ones located at

Actually, it would be a minimum, since a lot more could be done with
scaffolding, such as creating master-details scaffolding and changing
way to deal with dates (having a lot of selects for handling dates is
practice at all).

But the issue that concerns me more is localization, no doubt! All the
remaining can be done without too much complexity, but I don't see a way
solving the localization problem in a good way...

Any thought on that?


PS.: I would be very glad with Rails if I only had to develop English
sites... :(
1a1551a3a11e750cd46e5699cb175941?d=identicon&s=25 Rodrigo Rosenfeld Rosas (Guest)
on 2007-06-20 20:41
(Received via mailing list)
Sorry for the duplicated message but I couldn't send from newsgroup so I
tried directly on google groups. Result: both were published, although
newsgroup has arrived too late...


This topic is locked and can not be replied to.