Re: ITP: language
Hi,
From: Sebastian Leske <sleske@enterprise.mathematik.uni-essen.de>
Subject: Re: ITP: language
Date: Thu, 17 Feb 2000 13:49:41 +0100
> That\264s an interesting point, I had not thought about that before.
> It\264s true that enabling languages whose scripts are not so well
> supported in Linux at present (such as Japanese(?)) can cause
> trouble.
> Still, I was thinking from a user\264s perspective: On many systems (such
> as the one I help to administer) most people have the same native
> language. On those systems the most reasonable default for
> the language is the native language of most users. Otherwise
> all users individually have to reconfigure the system to use
> their language, that seems quite user-unfriendly to me
> (plus many users don\264t know how to do it, and thus never
> get the benefit of locales).
Yes, I understand your viewpoint.
BTW, what's '\264'? Ah, I understand it is an ISO-8859-1 character
like '''.
(http://www.kudpc.kyoto-u.ac.jp/~yasuoka/CJK.html)
> In any case, if things actually break and no longer work
> properly when setting LANG=some_language, that\264s a bug
> (in the malfunctioning program or in the locale) which
> should be fixed.
Yes and no.
I think we have to consider it a bug that Linux console cannot
display Japanese, for example. However, I think I am too radical
to the real status.
Even if all technical problems is solved, some language-related
coonfigurations have to be left to users' preference. For example,
there are several input method softwares for Japanese.
Many standards also have to be determined for fix the 'bug'. For
example, there are no standards on interface for input method software
for console, though XIM is for X Window System.
Chinese, Japanese, and Korean languge need many characters. Thus
there are not enough fonts for these languages. This is why GNU
Emacs cannot display Japanese by default setting even if Japanese
fonts are installed because there are no bold nor italic fonts for
Japanese.
Almost all editors and text-precessing softwares have to be rewritten.
There are many languages in the world. Even after many years when
Japanese will be fully supported like German, there will be languages
which is not well supported. Some of them are written from right
to left, some use combined characters, some are written vertically,
and some don't have any coded character sets.
I think at least all of us have to use UTF-8 to fix the 'bug'.
UTF-8 united Chinese, Japanese, and Korean characters which has
different shapes to save coding space. Some mechanism to choose
proper font should be developed.
Thus this 'bug' is very difficult to fix. Of course we, Debian JP
Project, are making efforts to fix it. However, even when all
softwares included in Debian potato is fixed, many new softwares
will be developed with such a bug by programmers who don't know
about internationalization. This is why I think it is important
to talk about techniques on localization and internationalization
in English language. Check 'Introduction to i18n' at Debian
Documentation Project web page.
And more, beyond internationalization, we have an goal of
multilingualization. We have only one truely multilingualized
software --- Mule (Multilingual Enhancement to GNU Emacs).
> Therefore, not using a locale setting as a default because
> it causes problems seems a bug workaround to me.
I *DREAM* a system whose such bugs are all fixed.
But we need such bug workaround now, and maybe for several years
or more.
> > Especially, the 'global' setting will affect
> > root user, which most Japanese people regard too dangerous and
> > hate. I think most Japanese user don't set LANG variable for
> > root user. I think German root user also should not use LANG=de.
> Could you explain that? Where are the security
> implications in using LANG=de (or whatever)? Programs work just
> the same (at least they should).
For example, the root user invokes some important commands at Linux
console (which cannot display Japanese) and the commands output
some message in Japanese. They cannot be read.
---
Tomohiro KUBOTA <kubota@debian.or.jp>
http://surfchem0.riken.go.jp/~kubota/
Reply to: