From: "Hal E. Fulton" <hal9000@...>
Date: 2003-03-07T05:22:51+09:00
Subject: Re: Internationalization

----- Original Message -----
From: "MikkelFJ" <mikkelfj-anti-spam@bigfoot.com>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Thursday, March 06, 2003 1:53 PM
Subject: Re: Internationalization


> I really do appreciate the tolerance of off-topic threads in this group.
> But could we please end this very long thread on Esperanto. Feel free to
> continue the discussion once a relevant RAA entry has been documented in
> said language.

Of course, now that you have said that... someone will
do so. :)

And if someone does, please don't document it *only* in
Esperanto.

Not to continue this thread... but there is one possible
justification for using Esperanto in this way. (Those who
wish to agree or disagree may do so offlist to de-clutter
the ML.)

It seems possible to me that Esperanto might provide a
"less rich" vocabulary -- and I mean that in a positive,
not a negative way.

This would allow disambiguation by "narrowing the pipe"
in the translation process. For example, a Japanese word
X might map to a large number of possible English words;
but it might (hypothetically) map to a single Esperanto
word. And then that would map (I hope) to a small(er)
number of English words or even a single word.

So my theory is that an automated two-step process might
be more accurate than a single-step process like Bablefish
or something (provided Esperanto or some similar conlang
were used as the intermediate).

This reminds me of the situation where you have N outputs
going into K inputs in a many-to-many fashion, with all
speaking different file formats or protocols. (Surely you
have seen this real-life situation? I can't give a concrete
example right now.)

The brute force solution, of course, is to implement N*K
translators... for large values of N and K, this of course
becomes prohibitive. The smarter solution is to establish
a common format or protocol, and write N translators to go
*to* that format and K to go *from* it... resulting in
only N+K modules being written.

> If people would just provide good examples of their modules in Ruby,
> possibly also with Test::Unit, the Japanese/Russian/English etc. problem
> would essentially be solved. Most Japenese developers know enough english
to
> name their functions but sometimes have problems with forming sentences.

Yes, Ruby is the universal language... but I have to admit
there are times when code alone is not enough for me to
understand the coder's intent, even in Ruby.

Cheers,
Hal