🚀 go-pugleaf

In article <24479@alice.att.com>
	andrew@alice.att.com (Andrew Hume) writes:

>	however, as i hinted and perhaps should have emphasised,
>plan 9 does not address i18n as such. although support for large
>or alternate characters is a prerequisite to i18n, you need a bunch more.

Surely.

>Locales, in this sense, are a complete and utter mistake.
>don't misunderstand me, they are totally wrong as well.

I agree with you.

>	the more insidious problem is that a bunch of the locale functionality
>(and certainly most of the stuff about language and scripts) is
>bound tightly to the data, and not to the processing of it. for example,
>japanese better get rendered as japanese no matter what your locale is.

I heard that, microsoft's NT will have a locale mechanism so that
it can print Japanes Han as Japanese and Chinese Han as Chinese,
which is impossible with bare 10646/Unicode.

Then, how can we have a file containing both Japanese and Chinese?

>another example is the issue of system error messages; what language
>(for example) should they be in?

>customer satisfaction is high
>until the first time someone attaches a file server with dutch language
>errors, follows a sym link through a file server attached with french
>messages, and the file doesn't exist.

Shouldn't we use error numbers internally and interprete it by local
programs?

							Masataka Ohta