From: Mike Calder <ceo@...>
Date: 2004-05-05T02:20:23+09:00
Subject: Re: Strange behaviour of Strings in Range

On Tuesday 04 May 2004 17:27, Hal Fulton wrote:
>
> Can you do that with any language whatsoever? Don't say Java, because
> it's limited to Unicode.
>
> It's not a flame. It's an honest question. Is there any programming
> language/environment *anywhere* where I18N issues are completely
> abstracted away and everything is done "nicely"?
>
> Hal

No flame understood, and none intended here either, but I didn't ask for I18N 
issues to be completely abstracted away.  I said I wanted to be able to write 
in one language, to not have to consider the string encoding when writing 
code, and for any other language user to be able to use the code just by 
translating the strings.  I probably misunderstand the situation (I often do 
until people beat the details into my head with hammers) but as far as I can 
see and in my practical experience Unicode (and by transference Java) gives 
me an "abstracted-enough" solution, for my applications with new data 
generated by my applications. 

If I understood the nature of the problems with Unicode stated earlier in this 
thread (and I must admit I skimmed a lot of it) it is based on there not 
being a unique encoding for all possible glyph/character representations in 
all languages (e.g., 1 unicode for a glyph which represents different 
characters in different languages), legacy encodings and legacy encoded data, 
and so on.   So you tell me Unicode doesn't hack it and you want to use 
something else.  I have no problem with that; I'm not emotionally attached to 
Unicode (or Java, come to that - that's why I'm looking, after all).

These problems may cause operational difficulties, and a totally clean 
solution probably has to handle all of them.  Meantime, in the real world 
(and on my plate), there is a need for I18N which ASCII just doesn't hack.

All I know is that using Java and Unicode I can write code in English, and 
have people translate it to any European language (including Cyrillic and 
Greek), into Hindi and Japanese, use it with those langauges, and it looks 
and behaves right in that target language.  I know, because it's both 
required and been done on code I've written.

The only points I'm making are that;

1) When you get round to implementing whatever (let's call it SuperCode) in 
Ruby, it should be part of the core and transparent to the user of String 
methods, and 

2) Until Ruby does with SuperCode or whatever what Java does today with 
Unicode, it's no use to me for production code and remains an (albeit pretty) 
toy as far as my practical applications are concerned.

-- 
Clear skies!
Mike Calder.