Fw: Multi-Language Support
Serg N Elin
But the world still hasn't good solution for localization and all what
we have now in not enough for it...
After research some availible docs about i10n and i18n i decided that
the best way for now is using UNICODE for whole system. When i finish
research some additional documents i will try to create something like
recommendation for i10n where i will try to
show independent (i hope ;) view on that problem.
Linux and other systems still hasn't good good solution for that
problem too...
> >Yeah.. I know things are workable. But coming from a linux background
> >and knowing their i18n environment are taking off nicely make this hack
> >method a bit tough to swallow.
> >
> >I searched the mailing list and the last time there is any talk about
> >an i18n environment is back in 1997. Does anyone know if the status of
> that
> >project? If not, I am willing to resurrect that project and see if there
> is
> >anything
> >we can do about it...
> >
> >Ray
> >
> >
> >Kevin Sez:
> >> > Kevin wrote:
> >> > > The OpenBSD doesn't support locale yet. If you want to see Chinese,
> >> > install
> >> > > chinese/taipeifonts; if you want to type in Chinese in terminal, you
> >would
> >> > > install chinese/crxvt and chinese/xcin.
> >> > >
> >> > So there is no locale mechanism within openBSD?
> >>
> >> Right. But things aren't so bad, you can use chinese/{crxvt+xcin} to type
> >in
> >> Chinese :)
> >>
> >> - Kevin
> >>
> >>
> >
> >
> >
>
>
Seth Arnold
There is much more to the problem of i18n and l10n than finding a good
method of representing all possible characters. It also involves having
libraries that make including different translations easy for a program,
accepting different inputs from users to do the same tasks, all this in
addition to people who are able to make translations available.
Just recompiling everything with an idea of using Unicode characters
won't solve the problem.
I think the GNU gettext library has done a fair job of helping
programmers write programs that are easy to localize. (I've never used
it myself, so I cannot judge from first-hand experience.)
* Serg N Elin <cr...@reclama.ru> [001005 00:01]:
Kamo Hiroyasu
Subject: Re: Fw: Multi-Language Support
Date: Thu, 5 Oct 2000 10:52:41 +0400 (MSD)
> But the world still hasn't good solution for localization and all what
> we have now in not enough for it...
> After research some availible docs about i10n and i18n i decided that
> the best way for now is using UNICODE for whole system. When i finish
> research some additional documents i will try to create something like
> recommendation for i10n where i will try to
> show independent (i hope ;) view on that problem.
Two points. First, UNICODE is just a character set, which is a small
part of i18n. Second, yes, you can use UNICODE for l10n or i18n, but
UNICODE is harmful for m17n because of the CJK unification.
I know using UNICODE is a better solution for users of
Latin/Greek/Cyril letters than using ISO 8859. But you should know
that there also are civilizations outside Latin/Greek/Cyril.
Kamo Hiroyasu
[Kamo is the family name and Hiroyasu the given name.]
ray
Cool! let us know when you are done researching.
I will do some research too. There will be a paper presented in BSD
conference about
i18n. I will try to attend that. Maybe I will get some insight on i18n. :-)
Seth and Hiroyasu:
Yes, you are right. Charset is just a part of an i18n environment. There are
other elements
such as input method, display, message translation etc... that must be
considered as well.
I understand that Unicode only contains the partial character set for many
asian language.
But I must say it is a decent attempt to create an uber-character set that
encompasses most
of the major languages. It help ease the problem of portability in an i18n'd
environment.
I can transfer a chinese text coded in Unicode from my computer that has a
Chinese locale
to my friend's computer that has a Polish locale, and it will still be
displayed correctly! (in an
ideal world)
This issue about unicode brings up a very good point-- i18n is more than
just displaying
text. It is about creating an infrastructure that facilitates programmers in
localizing their
software and making sure their product is still portable in this global
market. No one has
yet found a perfect solution, but we are getting closer. Any idea on what
would be an
improvement over GNU/Linux's approach to i18n?
I read through the design/implement policy of the Citrus project, but I wish
I can find more
detailed documents about their work. Does anyone know where these documents
are hiding?
Ray