On Tue, Jul 01, 2003 at 06:10:51AM +0900, Hal E. Fulton wrote:
> I see your point, and someone else expressed the same opinion.
> 
> But I stand by this principle. I like it personally, whether
> others do or not.
> 
> Personally I don't want to sprinkle 'tputs' and such throughout
> my code. I want to modify my code as little as possible.
> 
> Besides, a name like tputs will lead the reader subconsciously to
> think that something unusual is happening, when it is really (in
> effect) just a puts. Sure, it's doing a translation, but I want
> the programmer NOT to think about translation as he looks at 
> the code.
> 
> In other words, I want translation to be as transparent and 
> behind-the-scenes as possible.

Maybe such a low-level transparent translation belongs either in String, or
in the IO class, rather than overriding all the various Kernel#puts-type
methods.

Then you could make it explicit:

   $defout = TranslatingIO.new("en","de",STDOUT)
   puts "Hello world"    # >> "Hallo Weldt" or whatever

It might then be more general - for example it could be used on StringIO
objects - but less intrusive.

But I take your point that it's your project so it's up to you to design it
how you like :-)

I don't think I'd use the proposed style of library. Firstly it would be
very difficult to ensure complete coverage of all strings having
translations [unless there was a utility to parse the Ruby source to extract
all strings, and tie them up against all translations, and highlight any
missing ones]

Also I'd be a bit concerned about phrases where the word order might need to
be different in different languages:

    printf("I gave the %s to %s", thing, recipient)

It could perhaps use tags which were automatically stripped out in
translation:

    printf("I gave the <THING:%s> to <RECIP:%s>", thing, recipient)

Also, do we worry about languages where word endings change dependent on
function? Languages which require noun.capitalize ?

Regards,

Brian.