🚀 go-pugleaf

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

>> >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.
>
>	this is a fundamental and persistent misapprehension of
>10646. it was neither designed for, nor can it allowd a system
>to display identical Han characters (same 10646 codepoint)
>in different fonts WITHOUT some other (non-10646) convention.

As it defines the same code point for correnponding Japanese/Chinese
characters, differentiation is impossible.

>10646 simply defines codepoints, allowing the unambiguous specification
>of the characters. if you want to set (or switch) fonts, then you
>have to invent some scheme to do it, as say ISO 2022 does
>(in a slightly clumsy way).

Then, why you use ISO 10646? Can't we use ISO 2022?

>	i claim NT has some convention in addition to the locale
>(perhaps, it is part of the lcoale's definition) so it can do this.
>but i don't know.

Then, how can I create a text file which contains both Chinese
and Japanese?

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

>	when the protocol was updated, this was taken out
>and errors are now just text strings (64 bytes i think).

Making everything English text is another fatal misdesign of Plan 9
as an internationalized OS.

>	the bottom line is, when you connect to remote services,
>there is simply no way to know what they might report as errors.

If you are connecting to some server, you know the protocol you use
in which meanings on error numbers are contained.

>the problem is that a file server, say, may have an arbitrary
>number of error conditions, many of which may not be known locally.

Or, how can the client program know the severity of the error? Should
client program retry on error? How many times? Or should the client
abort the current transaction and retry? Or should the client
abort the entire job?

Even if the version of the server is updated and new error codes are added,
the server should know the version of the client and return old error code.
Or, how can the client program behave? Of course, for purely
informational purpose only, you can still report it, say, as "unknown
error # 42", which is of no help.

						Masataka Ohta