This is the mail archive of the davenport@berkshire.net mailing list for the Davenport project.


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

Re: DAVENPORT: Maintaing documents for multiple languages


/ Adam Di Carlo <adam@onshore.com> was heard to say:
| I once put forth that the right way to do this was through SGML marked
| sections, which basically is the SGML way to do the same thing:
| 
| <![ %FR [
| Guide d'utilisation et de configuration des produits HP sous Linux
| ]]>
| <![ %EN [
| Utilisation and Configuration Guide of HP products under Linux
| ]]>
| 
| I have indeed used this sort of technique before.  However, Norm
| argued quite compellingly that generally, this sort of thing should be
| done on the style level.

Since I don't think I made those arguments on this list, let me
recapitulate two of the disadvantages of marked sections:

1. They aren't valid in XML.
2. After parsing, the IGNOREd sections are *gone*. The parser throws
   them away. This means that you can never write a tool that uses
   a standard parser that can check for the 1-to-1 correspondence of
   chunks or do anything with both languages.

| It really wouldn't be too hard to filter
| language-dependent elements on the LANG attribute, e.g.:

And here we see a good example of the one thing you can't do (easily)
with attributes:

<article>
 <title>...</title>
 <subtitle lang="fr">
 Guide d'utilisation et de configuration des produits HP sous Linux
 </subtitle>
 <subtitle lang="en">
 Guide d'utilisation et de configuration des produits HP sous Linux
 </subtitle>

You can't have two subtitles, so this won't validate. Sigh. Damned if you
do, damned if you don't.

In this case, you could say:

<article>
 <artheader>
 <title>...</title>
 <subtitle lang="fr">
 Guide d'utilisation et de configuration des produits HP sous Linux
 </subtitle>
 <subtitle lang="en">
 Guide d'utilisation et de configuration des produits HP sous Linux
 </subtitle>

and then it would parse OK. But sitting in an airport at 6:30 in
the morning, I can't promise that there aren't cases in DocBook
where this conflict is unavoidable.

| > BTW, may I use that list to ask some questions on the DTD DocBook
| > and the sgmltools. If these questions are not adequate here, please
| > forgive me and give me the right places to find more documentations
| > or the right people :-)
| 
| SGMLtools has it's own list, see the sgmltools website.

On the other hand, questions about the DTD should definitely be asked
here.

| > I hava also problems with URLs. They are correct in the HTML. But they
| > don't appear at all in the PS (I would like at least a note at the end of the
| > page or something like lynx does when it dumps a page).

If you (define %footnote-ulinks% #t) in your stylesheet, you'll get footnotes
for the URLs of <ulink>s.

| The best solution here is to go with PDF.  The Jade TeX backend and
| JadeTeX support links in PDF.

Yeah, but my solution works with all the print backends <wink/>.

                                        Cheers,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Anything more than the truth would
http://www.oasis-open.org/docbook/ | be too much.--Robert Frost
Member, DocBook Editorial Board    | 


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