Forum: Ruby on Rails i18n when?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Harm de Laat (Guest)
on 2006-01-30 11:38
(Received via mailing list)
Hi all,

Just wondering... Are there any plans to include i18n support in Rails
anytime soon?
I guess this is about the only feature I'm realy missing in Rails.

Any thoughts?

Regards,

Harm de Laat
NoobSaibot (Guest)
on 2006-01-30 11:57
second that!
Kasper W. (Guest)
on 2006-01-30 13:54
> Just wondering... Are there any plans to include i18n support in Rails
> anytime soon?

Take a look at http://www.globalize-rails.org/wiki/

Kasper
Nicolai R. (Guest)
on 2006-01-30 13:57
(Received via mailing list)
David stated in the "Snakes and Rubies" video (
http://www.djangoproject.com/snakesandrubies/), I18N is not difficult in
a
technical way. It's mostly string replacement.
dseverin (Guest)
on 2006-01-30 14:43
Nicolai Reuschling wrote:
> David stated in the "Snakes and Rubies" video (
> http://www.djangoproject.com/snakesandrubies/), I18N is not difficult in
> a
> technical way. It's mostly string replacement.

No, it's not that easy, as I18N is a bit more complicated, and  requires
enforcement of some rules about code and data organization, see
http://www.unicode.org/faq/basic_q.html#4 ,
http://www.unicode.org/faq/basic_q.html#13  for example.

At present time Rails can't even handle UTF8 properly, and you ask I18N?

I18N will be in Rails only as soon as *you* will implement it, don't
rely on core team, thay have a lot more things to improve and fix, and
I18N isn't what they are paid for.
Jeroen H. (Guest)
on 2006-01-30 15:11
(Received via mailing list)
dseverin wrote:


> At present time Rails can't even handle UTF8 properly, and you ask I18N?

Could you elaborate on this? It seems to be working alright for me.

Jeroen
dseverin (Guest)
on 2006-01-30 15:31
Jeroen H. wrote:
> dseverin wrote:
>
>
>> At present time Rails can't even handle UTF8 properly, and you ask I18N?
>
> Could you elaborate on this? It seems to be working alright for me.
>
> Jeroen

It also seemed to work alright for me, but once it began to fail :(

http://www.fngtps.com/2006/01/encoding-in-rails#comment24

Could you just review the code of mentioned there components and tell me
that *it will never break* on UTF8?

E.g. validates_length_of is definitely broken,
String#blank? doesn't take into account ALL Unicode space chars,
active_support/core_ext/string/access.rb is completely broken,
action_view/helpers/text_helper.rb has "fixed" truncate(), but broken
excerpt()

-- and that list can be still incomplete...
Jeroen H. (Guest)
on 2006-01-30 15:46
(Received via mailing list)
dseverin wrote:
>
>
> -- and that list can be still incomplete...

Yes I'm afraid you're absolutely right. There also a wiki entry about
this: http://wiki.rubyonrails.com/rails/pages/HowToUseUn...

You would think a Japanese language would handle this properly though?
Couldn't you globally alias all string methods to use their UTF-8
equivalents once kcode='utf-8' ? I still know very little about rails
internals and ruby so I don't really know if it's hard to fix.

Jeroen
Alex Y. (Guest)
on 2006-01-30 15:58
(Received via mailing list)
Jeroen H. wrote:
> You would think a Japanese language would handle this properly though?
I'm no expert, but apparently UTF-8 is far from the most popular
Japanese encoding, and there are allegedly some very cogent arguments
against it that aren't a matter of NIH syndrome.  That's why Ruby
doesn't do Unicode well - not because it's not been thought about, but
because it's been thought about too much :-)

> Couldn't you globally alias all string methods to use their UTF-8
> equivalents once kcode='utf-8' ? I still know very little about rails
> internals and ruby so I don't really know if it's hard to fix.
It is :-)  Once you lose the assumption that a codepoint is one byte,
the concept of String#length gets really murky, for example.
dseverin (Guest)
on 2006-01-30 16:13
Alex Y. wrote:
>> Couldn't you globally alias all string methods to use their UTF-8
>> equivalents once kcode='utf-8' ? I still know very little about rails
>> internals and ruby so I don't really know if it's hard to fix.
> It is :-)  Once you lose the assumption that a codepoint is one byte,
> the concept of String#length gets really murky, for example.

Yes, and you can have up to *three* lengths: String#byte_length,
String#codepoint_length, String#grapheme_cluster_length (e.g. NFD in
MacOS filenames).

Besides:
1. Most of Rails internal processing expects ASCII strings (routing and
template path magic, SQL model_table_name <-> ModelTableName etc), and
expect one byte - is one ASCII char.

2. Overriding globally String methods with their UTF8 equivalents is
risky, and can give unpredictable faults (Julian's unicode_hacks caused
Webrick work improperly, and in my application ActionMailer failed), as
different parts and libraries which  they reference can expect exactly
*byte* String methods.

So, I think, as it will hardly be fixed (YAGNI, men, YAGNI, web 2.0 is
ASCII!) i18n is still in distant perspective.
Alex Y. (Guest)
on 2006-01-30 16:36
(Received via mailing list)
dseverin wrote:
> Yes, and you can have up to *three* lengths: String#byte_length,
> String#codepoint_length, String#grapheme_cluster_length (e.g. NFD in
> MacOS filenames).
My point precisely.  And then what do you do about the byte order mark?

> Besides:
<snip>
> So, I think, as it will hardly be fixed (YAGNI, men, YAGNI, web 2.0 is
> ASCII!) i18n is still in distant perspective.

Maybe not that far off.  According to this:
http://redhanded.hobix.com/inspect/futurismUnicode...
YARV should handle strings a little more sensibly.  Once that's in
place, the string replacing aspect should be a little simpler.
Masao M. (Guest)
on 2006-01-30 19:56
(Received via mailing list)
Hi,

On Mon, 30 Jan 2006 14:31:57 +0100
dseverin <removed_email_address@domain.invalid> wrote:

> It also seemed to work alright for me, but once it began to fail :(
>
> http://www.fngtps.com/2006/01/encoding-in-rails#comment24
>
> Could you just review the code of mentioned there components and tell me
> that *it will never break* on UTF8?
>
> E.g. validates_length_of is definitely broken,

I've used a patch below.
It works well at least Japanese/UTF-8.
#You need to call $KCODE="u" first.

--- validations.rb.old  2006-01-31 02:22:42.000000000 +0900
+++ validations.rb      2006-01-31 02:41:03.000000000 +0900
@@ -459,7 +459,7 @@
           message = (options[:message] ||
options[message_options[option]]) % option_value

           validates_each(attrs, options) do |record, attr, value|
-            record.errors.add(attr, message) unless !value.nil? and
value.size.method(validity_checks[option])[option_value]
+            record.errors.add(attr, message) unless !value.nil? and
value.split(//).size.method(validity_checks[option])[option_value]
           end
         end
       end

It may be better to adde String#char_length something like as:

class String
  def char_length
    split(//).size
  end
end
Curt S. (Guest)
on 2006-02-02 02:36
(Received via mailing list)
On Mon, 30 Jan 2006, Alex Y. wrote:

> Jeroen H. wrote:
>> You would think a Japanese language would handle this properly though?
>
> I'm no expert, but apparently UTF-8 is far from the most popular
> Japanese encoding, and there are allegedly some very cogent arguments
> against it that aren't a matter of NIH syndrome.

I feel that I'm pretty familiar with this. I live in Japan, speak, read
and write some Japanese, and have done a fair amount of I18N work for
English+Japanese web sites.

The arguments Japanese critics have against Unicode are, for the most
part, complete rubbish. They sum up to more or less the following:

     1. Unicode 1.0 has issue X. Answer: err...try using maybe only a
     five-year-old spec., like Unicode 2.0? Or get really genki and
     upgrade to 3.0, maybe even before 4.0 comes out!

     2. Important characters are missing. Answer: they're missing from
     JIS character sets, too. And more are missing from JIS character
     sets than Unicode. Unicode has *every single character* available
in
     Shift-JIS, EUC-JP and ISO-2022-JP, so if you're switching from
those
     (which is what almost every system in Japan uses), you lose not one
     single character you had before.

     3. You can't tell the difference between Chinese and Japanese
     in Unicode. Answer: in the same sense that you can't tell the
     difference between French and English in ISO-8859-1. We have other
     methods for doing that that don't involve adding characters to a
     character set. (Some Japanese apparently feel that Unicode should
do
     the equivalant of having different "French" and "English" versions
     of the letter "a".)

     4. UTF-8 takes more space. Answer: on a typical web page, it takes
     7% more space than Shift-JIS or EUC-JP. It's not a big deal, and
     is actually a very small price to pay for the benefits you get.
     However, there are other encodings available.

The Japanese critics tend to ignore other things that benefit them.
Some, they just don't care about, such as the ability to have French and
Japanese on the same page. Others, such as having "generic" web-based
message board systems and other programs "just work" without any extra
effort on the part of a foreign developer, they really ought to care
about, because it will save them money in a very direct way.

Anyway, there's my rant for the day.

cjs
--
Curt S.            <removed_email_address@domain.invalid>             +81 90 
7737 2974
   The power of accurate observation is commonly called cynicism
   by those who have not got it.    --George Bernard Shaw
Julian 'Julik' Tarkhanov (Guest)
on 2006-02-02 14:11
(Received via mailing list)
On 30-jan-2006, at 14:44, Jeroen H. wrote:
>>
>
> You would think a Japanese language would handle this properly
> though? Couldn't you globally alias all string methods to use their
> UTF-8 equivalents once kcode='utf-8' ? I still know very little
> about rails internals and ruby so I don't really know if it's hard
> to fix.

I did exactly that in my Unicode Hacks plugin, however it breaks
other software in a nasty, unpredictable way.
The article by Thijs on Fingertips (incl. the comments) analyzes the
breakage more thoroughly.

--
Julian 'Julik' Tarkhanov
me at julik.nl
Julian 'Julik' Tarkhanov (Guest)
on 2006-02-02 14:11
(Received via mailing list)
On 30-jan-2006, at 15:13, dseverin wrote:


>
> So, I think, as it will hardly be fixed (YAGNI, men, YAGNI, web 2.0 is
> ASCII!) i18n is still in distant perspective.

I wonder what you were smoking
--
Julian 'Julik' Tarkhanov
me at julik.nl
Siva J. (Guest)
on 2006-02-02 19:31
(Received via mailing list)
Look at Localization package
--
Rgds,
--Siva J.
http://www.varcasa.com/
My First Rails Project.
Education Through Collabration
This topic is locked and can not be replied to.