This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Language code for FPIs -- not explicit enough?
- To: docbook at lists dot oasis-open dot org
- Subject: DOCBOOK: Language code for FPIs -- not explicit enough?
- From: Nik Clayton <nik at nothing-going-on dot demon dot co dot uk>
- Date: Sun, 26 Sep 1999 18:02:34 +0100
- Organization: Nik at home, where there's nothing going on
- Reply-To: docbook at lists dot oasis-open dot org
Hello *
[ I'm not convinced this is 100% on topic for this list. My apologies
if it isn't (doubtless the moderator will let me know in due course) ]
In managing the FreeBSD documentation set, we're starting to get chunks
of documentation that should be reused in many places. For example, at
the start of a 'book' we want to include a boilerplate legal notice.
I'm trying to organise these fragments, and use FPIs and a catalog to
use them. For example;
...
<ENTITY % bookinfo PUBLIC "-//FreeBSD//ENTITIES DocBook BookInfo Entities//EN">
%bookinfo;
...
<bookinfo>
<legalnotice>&bookinfo.legalnotice;</legalnote>
...
...
and so on. So far, this works nicely.
You could extend this to French fairly easily; just put the definitions in
another file, and use "//FR" on the end of the FPI instead.
The problems arise when you start using languages with multiple possible
encodings. For example, Chinese can be written in two encodings, EUC, and
Big5. You can't distinguish between them with this scheme, so simply
using "//ZH" in place of "//EN" in the FPI isn't sufficient.
FWIW I think, but could be wrong, that Norm's stylesheets have a similar
problem. Specifying the default language with "<book lang='zh'>" isn't
sufficient either, as the various bits of boilerplate emitted by the
stylesheets would need to be in the correct encoding.
Does anyone have any thoughts on the best way to solve this problem? The
most obvious solution is to specify the encoding in the FPI like this
<!ENTITY bookinfo
PUBLIC "-//FreeBSD//ENTITIES DocBook BookInfo Entities zh_TW.Big5//EN">
i.e., ignore the language specifer in the FPI, and include it in the
description. This strikes me as being less than optimal because you then
have important meta information inside what is (I think) supposed to
freeform data.
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in <375143b5@cs.colorado.edu>