Bug#151531: dselect UTF-8 bug not fixed
At Mon, 1 Jul 2002 16:54:00 +0200,
Michael Piefel wrote:
> On 1/07/02 at 14:53:40, Wichert Akkerman wrote:
> > It's not a bug.
> Well, I believe it is. You count the number of characters in the string,
> perhaps using strlen or some other non-UTF-8-aware function.
Well, strictly speaking, "not UTF-8-aware" itself is NOT a bug. However,
"not obeying LC_CTYPE locale" is a bug. In UTF-8 locales, softwares
must work in UTF-8.
However, since UTF-8 is rather a future encoding, UTF-8 should be
omitted from a list of required encodings.
On the other hand, there are encodings which are not 8bit nor are
not UTF-8. They are not future encodings but current encodings.
They are --- EUC-JP, EUC-KR, GB2312, and Big5. I think that softwares
which don't support these encodings are really buggy, like softwares
which don't support 8bit encodings (not 8bit clean) are regarded to
be buggy today, and there are people who are trying to fix these "bugs".
I am one of them.
Like that, if you think non-UTF-8-supporting softwares are buggy,
please fix it. Many people, especially Arab, Hebrew, Khmer, Indian,
Thai, and east Asian people will thank you. Really.
Tomohiro KUBOTA <firstname.lastname@example.org>
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org