Re: Open letter to Debian community
- To: Tomohiro KUBOTA <firstname.lastname@example.org>
- Subject: Re: Open letter to Debian community
- From: The Doctor What <email@example.com>
- Date: Thu, 1 Feb 2001 08:27:24 -0600
- Message-id: <20010201082724.A26522@gerf.org>
- In-reply-to: <firstname.lastname@example.org>; from email@example.com on Thu, Feb 01, 2001 at 01:36:20PM +0900
- References: <firstname.lastname@example.org> <20010130223223.A4897@x8b4e5089.dhcp.okstate.edu> <20010131104606.A29069@gerf.org> <email@example.com>
* Tomohiro KUBOTA (firstname.lastname@example.org) [010131 22:30]:
> What is the meaning of 'languages are supported by a package'?
> I mean, for CJK (Chinese, Japanese, and Korean, i.e., multibyte-language
> speakers) people, multibyte encoding support is much more important
> than translations. For example, we are very glad to use a word
> processor which we can input CJK languages even though it has no
> CJK translations, because so far multibyte-enabled softwares are
> sorare that we cannot complain about translations. (Note that
> softwares without translations are merely _inconvenient_ while
> softwares without multibyte support are _useless at all_.) This
> not only for word processors but also all for softwares which has
> text processing, like perl, grep, awk, sed, wc, shells (you input
> text on them), terminal emulators, web browsers, window managers
> (have to display window titles in multibyte), gimp (has text writing
> ability), and so on so on. In future, when these softwares will
> come to support multibyte encodings, then we will be able to want
> translations. Please consult my document "Introduction to I18N"
> for detail. ( http://www.debian.org/doc/manuals/intro-i18n/ )
I wasn't thinking about multibyte cleanness (which is a separate
issue to actually doing specific with a multibyte language). When I
said it supports, I guess I should have said, "Is documented with".
I am totally unaware of the number of packages in Debian that don't
support multibyte characters. It would probably be nice to have
this info listed someplace too.
> I think not only CJK but also Thai, Hebrew, Arab, and so on which
> need special processing like combining character and bidi are located
> in similar conditions.
I didn't think the software itself needed to be able to do special
processing. Worst case scenerio, you delete half (or a fraction)
of multibyte character which is irritating, but not desructive to
your work. Now, wordwrapping in the middle of a multibyte character
> In short, 'support for languages' has different meaning from language
> to language. Your 'control field' should be able to handle such
> special (but more important) cases.
Yes, support was a bad choice of words. I should have said "Has the
proper documentation for a language". IE, someone who reads Chinese
should be able to install, configure, and work with the software
without having to know any English. I'll qualify that and say that
I'm not counting things outside of the scope of the software (shells
that might be called, etc.)
The Doctor What: Need I say more? http://docwhat.gerf.org/