Date: Fri, 25 Jun 1999 09:46:11 +0100 From: Nik Clayton <nclayton@lehman.com> To: Satoshi - Ports Wraith - Asami <asami@freebsd.org> 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: <19990625094611.E15628@lehman.com> In-Reply-To: <199906250127.SAA82661@silvia.hip.berkeley.edu>; from Satoshi - Ports Wraith - Asami on Thu, Jun 24, 1999 at 06:27:16PM -0700 References: <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> <199906250127.SAA82661@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 24, 1999 at 06:27:16PM -0700, Satoshi - Ports Wraith - Asami wrote:
> * 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.
Er, yes. That's what I mean by "they might exist in several places when
they are installed".
> 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?
No and yes.
No, because the default installation directory (even with the new structure)
will stay the same after I've made the change.
Yes, in as much as (as the rest of my message explained) I want to give
the end-user more flexibility over where the documentation is installed.
This will include support for retaining the current installation locations,
which will always be available.
However, the "yes" code is still some way away, so is not an issue at the
moment.
> 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.
Yep. When I get a little more time I'm going to write up the end goal
and include some proof of concept examples that people can test out before
any of it is implemented in stone (as it were). We can then bash these
around to sort out a working design.
> * 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.)
Yep.
> 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.
That is likely, yes. However, if there's one thing that painful experience
has taught me is that if you design out a feature from something, you'll
implement it, only to discover that people start asking you for the very
feature you omitted in the first place.
Making it possible to do this (install different encodings, symlink to
a preferred default) is fairly easy, and provides some functionality that's
quite small but will probably be useful to someone. So I don't want to
design it out.
> 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).
What about
ja_JP.eucJP
and
ja_JP.SJIS
? (assuming "eucJP" and "SJIS" are the correct encoding names, which I'm
happy to accept)
There you need, language, territory, and encoding.
As soon as you need it for one you need it for all to keep the directory
names consistent.
Yes, you don't *have* to make the directory names consistent. But it
simplifies code that has to deal with them, makes documenting the standard
easier, and takes less 'head space' to deal with.
> * 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. :)
It doesn't. But it's got lots to do with divorcing the location of the
documentation in the repository with the location(s) of the documentation
when it's installed.
Which is what you were originally asking about.
>* 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.
References to good books, articles, and/or web sites to read on the subject
would be appreciated. I've done my own research, but not being able to use
the languages in question has obviously limited what I can do.
To twist the problem around for a second; suppose that we were just starting
the doc/ repository, but that we already had a body of English, Japanese,
and Chinese documentation (in two encodings), available, and ready to
import in to the repository.
Suppose, also, that you were aware that Unicode was hovering on the horizon,
and would need to be supported some time down the line, preferably with as
little upheaval as possible.
Knowing that, how would you design the doc/ repository?
My contention is that, with all that hindsight, you would choose to
segregate the docs by language, territory, and encoding, to try and be as
future proof as possible.
That's what I'm trying to do. The problem is the legacy repository, and
the effort involved in moving things around.
> * 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....
That's useful information. Cheers.
N
--
--+==[ Systems Administrator, Year 2000 Test Lab, Lehman Brothers, Inc. ]==+--
--+==[ 1 Broadgate, London, EC2M 7HA 0171-601-0011 x5514 ]==+--
--+==[ Year 2000 Testing: It's about time. . . ]==+--
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?19990625094611.E15628>