Date: Thu, 24 Jun 1999 18:27:16 -0700 (PDT) From: asami@freebsd.org (Satoshi - Ports Wraith - Asami) To: nclayton@lehman.com Cc: nik@nothing-going-on.demon.co.uk, doc@freebsd.org, freebsd-translate@ngo.org.uk, tech-jp@jp.freebsd.org, cvs@freebsd.org Subject: Re: FDP Directory Reorganisation Message-ID: <199906250127.SAA82661@silvia.hip.berkeley.edu> In-Reply-To: <19990624111012.L15628@lehman.com> (message from Nik Clayton on Thu, 24 Jun 1999 11:10:12 %2B0100) References: <19990603195027.A31941@catkin.nothing-going-on.org> <37593369.10E2888D@sky.rim.or.jp> <19990607233227.A34938@catkin.nothing-going-on.org> <199906162246.PAA02177@silvia.hip.berkeley.edu> <19990617194856.A26011@catkin.nothing-going-on.org> <199906172252.PAA11221@vader.cs.berkeley.edu> <199906181152.EAA24735@silvia.hip.berkeley.edu> <199906231041.DAA51528@silvia.hip.berkeley.edu> <19990623231108.A71294@catkin.nothing-going-on.org> <199906232344.QAA55779@silvia.hip.berkeley.edu> <19990624111012.L15628@lehman.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: Nik Clayton <nclayton@lehman.com>
* Because while the files will only exist in one place in the CVS repository,
* they might exist in several places when they are installed.
All examples you have given install things in one directory -- the one
with the same name as the repository -- and adds various symlinks to
make it accessible under different locations.
Let me rephrase the question. You said before:
> Doesn't apply. I'm not asking that the installation directory change,
> just the directory in which it's held in the CVS repository.
Can we take this as you are *not* going to change the installation
directory as a result of the CVS repository change? As long as
manpages and handbooks stay in {man,doc}/ja etc., the impact to
ordinary users and the ports collection is minimal and we can live
with that.
* Consider the Japanese translations.
*
* Right now we only have one encoding, EUC-JP in the repository. What's
* more, we can mechanically convert from EUC to ShiftJIS encoding (at least,
* I've been told on this list that we can do that).
Yes, mostly. They are basically just different code table -> bit
pattern functions for the same language. In fact, the conversion is
purely arithmetic so there is a simple mathematical formula to convert
between the three. (I.e., you don't even need a table lookup, as will
be the case if you want to convert between the three and Unicode, but
that's another story.)
* Now suppose that you're a Chinese admin, and you've got the choice of
* documentation that is available in two different encodings.
*
* You can install both of them (because the encoding names don't clash)
* and use a symlink from /usr/share/doc/zh to point to whichever one you
* want to be 'local preferred format'.
By the way, are you aware that Mandarin, Cantonese and Taiwanese are
actually very different languages? Danish, Swedish and Norwegians are
much closer to each other than the four major dialects in China. For
instance, Danish, Swedish and Norwegian people can easily understand
each other by everyone just speaking their own language -- the same
doesn't apply to Chinese. (Although the most of the Shanghainise
speakers and some Cantonese speakers are living in the mainland and
have been forced to learn Mandarin too -- similar to Polish and
Russian until 10 years ago.)
So it's really not very likely that your hypothetical "Chinese admin"
would want to install documents in both formats and point a "zh"
symlink to the "preferred format" -- it's not like many people can
understand both anyway. It's much more realistic to treat them as
different languages, such as English and Russian. They don't even use
the same set of letters.
Besides, what you've proven here is that there could be cases where
you might want a language plus the territory -- it has nothing to do
with encoding/codesets. zh[_CN] and zh_TW would be enough to
distinguish between the two (and that's exactly what X/Open is doing
as you can see in /usr/X11R6/lib/X11/locale).
* Suppose that you have 3 pieces of documentation about printing on Unix.
:
* with links to all the installed documentation, nicely categorised.
*
* How cool is that, eh? :-)
Cool, but I have no idea what this has to do with the name of
language-specific directories. :)
* No it's not (as a repository directory name). Directories in the repository
* will be encoding the language, location, and encoding. I want this to be
* an inviolate rule -- if we need it for one language, then, for future
* proofing, we need it for all.
You know, I really wish you guys learn more about our languages before
making sweeping generalizations like this. The Asian languages are
all quite different from European languages in many ways, and they are
all more of exceptions than the rule when it comes to
language/encoding landscapes. As I said above, "Chinese" is not one
language in terms of people being able to understand each other. The
differences between the three major encodings in Japanese are much
closer than that of Chinese, because they all basically start from the
same code table but use different bit patterns to encode them.
* Consider what happens as and when we provide a mechanism to mechanically
* translate from EUC to ShiftJIS (for example).
There are quite a few of those in ports/japanese already....
* I am 100% dead set against this being something like
*
* ja
* ja_JP.ShiftJIS
*
* directories instead. This is inconsistent with how the rest of the tree
* will be organised, and will required kludges anywhere the directory name
* is split apart in to its constituent components to take account of the
* fact that one of the Japanese directories is named differently.
I'm against something like that too. I just don't think any of your
strawman arguments hold water in real life.
Considering the trivialities of differences in encoding in Japanese,
the pain we had to go through when we changed the installation
directories last time, and the fragility of locale names (as I said,
there are at least five major variants out there today -- ja,
ja_JP.EUC, ja_JP.ujis, ja_JP.eucJP, ja_JP.EUC-JP -- all meaning
"Japanese EUC"), I am absolutely 100% against changing installation
directory names for Japanese documents. If we want to be able to
refer to them with different names, the symlinks should be from those
longer names to ja, not the other way around.
It doesn't make sense to me that you would want to change the CVS
repository names for documents without changing installation
directories, but if that's what you want, that's your prerogative.
Satoshi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906250127.SAA82661>