🚀 go-pugleaf

In article <2563@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
> In article <24479@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.
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).
	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.

> >another example is the issue of system error messages; what language
> >(for example) should they be in?
> 
> Shouldn't we use error numbers internally and interprete it by local
> programs?

	we couldn't figure out a way to do that in plan 9.
the problem is that a file server, say, may have an arbitrary
number of error conditions, many of which may not be known locally.
originally, plan 9's file system protocol returned numbers for
errors but part of the protocol was getting the text messgae for an
error number (so you could cache these lcoally in a program).
	when the protocol was updated, this was taken out
and errors are now just text strings (64 bytes i think).

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

	andrew