This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Language code for FPIs -- not explicit enough?


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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]