Hi, From: Sebastian Leske <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://surfchem0.riken.go.jp/~kubota/
