$
condition
. For example, let's say the book How To Use Product Foo has an "upstream", "enterprise", and "beta" version:
<para condition="upstream"> <application>Foo</application> starts automatically when you boot the system. </para> <para condition="enterprise"> <application>Foo</application> only starts automatically when you boot the system when installed together with <application>Bar</application>. </para> <para condition="beta"> <application>Foo</application> does not start automatically when you boot the system. </para> <para condition="beta,enterprise"> To make <application>Foo</application> start automatically at boot time, edit the <filename>/etc/init.d/foo</filename> file. </para>
$
condition: version
parameter to the publican.cfg
file and run the $
publican build
command as normal. For example, if you add condition: upstream
to the publican.cfg
file of How To Use Product Foo and run:
$
publican build --formats=pdf --langs=en-US
condition="upstream"
and builds How To Use Product Foo in as a PDF file in American English.
Root nodes and conditional tagging
Installation_and_configuration_on_Fedora.xml
contains a single chapter:
<?xml version='1.0' encoding='utf-8' ?> <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> <chapter id="chap-Installation_and_configuration_on_Fedora" condition="Fedora"> <title>Installation and configuration on Fedora</title> [text of chapter] </chapter>
User_Guide.xml
with an <xi:include>
tag, the document will not build with $
condition: Ubuntu
set in the publican.cfg
file.
<xi:include>
tag in User_Guide.xml
, not to the <chapter>
tag in Installation_and_configuration_on_Fedora.xml
.
xrefs and conditional tagging
<xref>
points to content not included in the build due to conditional tagging, the build will fail. For example, with $
condition: upstream
set in the publican.cfg
file, $
publican build --formats=pdf --langs=en-US
will fail if the book has the tag <xref linkend="betasection">
pointing to <section id="betasection" condition="beta">
.
Use conditional tagging with great caution
#. Tag: para #, no-c-format msgid "<application>Foo</application> starts automatically when you boot the system." msgstr "" #. Tag: para #, no-c-format msgid "<application>Foo</application> only starts automatically when you boot the system when installed together with <application>Bar</application>." msgstr "" #. Tag: para #, no-c-format msgid "<application>Foo</application> does not start automatically when you boot the system." msgstr "" #. Tag: para #, no-c-format msgid "To make <application>Foo</application> start automatically at boot time, edit the <filename>/etc/init.d/foo</filename> file." msgstr ""
publican.cfg
file and are aware of the valid conditions for your book, they cannot proofread their work. Without that knowledge, when translators proofread a document, they will wonder why they cannot find text that they know they translated and can find easily in the PO file. If you must use conditionals in your book, you must be prepared to provide a greater degree of support to your translators than you would otherwise provide.
upstream.cfg
file might contain the condition condition: upstream
and the enterprise.cfg
file might contain the condition condition: enterprise
. You could then specify the version of the document to build or package with the --config
; for example, $
publican package --lang en-US --config upstream.cfg
. Using two separate config files saves you from having to edit the one config file each time you build or package a document.