🚀 go-pugleaf

	just to get it out of the way, the name plan 9 is based on the movie
(as is clear when you see the CD-ROM Plan 9 is distributed on).

	there is a paper being presented by rob pike at the san diego usenix
on the plan 9 stuff (the postscript for that is freely available).

	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.
unfortunately, we don't have much idea on what more to do.
the problem is that there is no good model for doing i18n.
Locales, in this sense, are a complete and utter mistake.
don't misunderstand me, they are totally wrong as well.
having said that, i think the posix locale stuff has done a reasonably
good job of nailing down a bunch a details which need to be nailed down.
and apparently, a whole bunch of folks think that's the whole problem.
i think of it as doing the mil spec on shoelaces when we haven't decided
if we're walking or taking the bus.

	i feel obliged to give an example. locales seem to have an
underlying model that a user doing processing is doing that processing
in some local context (locale) with a number of conventions and rules
governing that processing. if this was all that happened, we'd be in
good shape. but hey, what about networking? there are two problems
here. one is almost trivial; suddenly ``local'' is undefined.
if i'm in berlin and rlogin to paris, which locale should i use?
(i think the answer is that the question is wrong; this use of locale
amounts to saying ``i want to view the world and all data i see through
a specific filter (locale)'' and the answer is the locale i am
familiar with.)

	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.
another example is the issue of system error messages; what language
(for example) should they be in? there exist a number of plausible solutions
to this problem but again, in the presence of networking, can get very
hard very quickly. imagine i supply a system where customers can attach
file servers with a language indicator. 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.

	i am not saying we can't fix these problems and more or less
get it all right. but we have to have a better model of how and to
what these attributes (that locales typically use) attach to.
locales will let us limp along for now, but they ain't the answer.

			andrew hume

p.s. don't forget that i am but one cog in the vast plan 9
juggernaut. other players may have radically different views
(on almost anything).