All KDE documentation is produced in DocBook XML format, and writers are encouraged to learn it (although it's by no means necessary, and we're very happy to receive documentation written in plain text). Although DocBook can look somewhat intimidating to beginners, the markup is extremely self-descriptive, and many people find it easier than HTML to learn.
In this chapter, we'll just take a basic overview of the ideas behind DocBook. For detailed information about individual tags and so on, please see Appendix A. DocBook Reference.
DocBook is just an application of XML, so if you're familiar with XML, then you'll feel right at home. If not, don't worry, as most of the gory details aren't required knowledge for simply writing and updating documentation. A DocBook file (and, indeed, any XML file) consists of plain text, with tags surrounding some text to tell you (or a computer) what that text represents. So, a snippet from a DocBook file might look like:
<para>To display the clipboard history, click on the &klipper; icon in the &kde; panel, or press <keycombo action="simul">&Ctrl;&Alt;<keycap>V</keycap></keycombo>. Previous clipboard entries are shown at the top of the popup menu which appears.<para>
</para> show the start and end, respectively, of a paragraph. These delimiting marks are called "tags", and the content they contain (along with the tags) is called an "element". The
<keycombo> tag has an extra piece of information specified:
action="simul". This is called an "attribute," and makes the tag more specific. The words surrounded by & and ; are "entities". They are simply variables that expand to some other text, and are widely used in KDE documentation. See KDE Specialities for more information about entities. Tags, entities, comments and other parts of XML that aren't simple text are referred to as "markup."
One of the basic principles behind the use of DocBook in KDE is that content and presentation are strictly separated. DocBook files contain the content, and XSL files contain the information about presentation. This has a number of advantages, some of which are:
In practice, this means that you should add markup that describes what things are and not how they should appear. So, in the example above, the
<keycombo> (a keyboard shortcut) tells the reader (or computer) that the keys Ctrl, Alt and V should be pressed simultaneously, but doesn't say anything about how that should be displayed in the final output. (In fact, it appears as "Ctrl + Alt + V", but it
could equally be converted to "C-M-V" à la Emacs or even some other way of showing keyboard shortcuts. What's important is that the DocBook source has the "information" necessary to work out what is being referred to.)
KDE-isms: entities, necessary bits (credits, translation stuff)
Entities (which are simply variables which expand to some other text) are an important part of DocBook markup, and are used particularly widely in KDE documentation. For example, there are entities defined for almost all KDE applications. Therefore, when referring to, for example, Konqueror in documentation, you should use:
&konqueror; is, among other things, a web browser.
This has several advantages. Firstly, it ensures that applications are capitalized and marked-up consistently across all KDE documentation. This means that you don't have to remember whether the help center program is KHelpCenter, KHelpcenter or Khelpcenter: the entity (which is always entirely lowercase) automatically expands to the correct one.
There are entities defined for several classes of names:
&ie;and "e.g." as
⪚. This ensures that the same markup and capitalization are used for these abbreviations throughout KDE documentation. Technological abbreviations such as HTTP and XML also have entities, which are capitalized as usual (i.e.,
&XML;for the previous examples).
trademarktag, using the
class="registered"attribute if necessary. To reduce effort, and ensure that trademarks are given proper acknowledgment, many common technology-related trademarks have been given entities. For example, the entity
&X-Window;expands to X Window System®.
&Firstname.Initial.Lastname). Email addresses of contributors have entities of the form
keysym. Since it can be difficult to distinguish between these two tags, entities have been created for common keys, e.g.,
The definitions of these entities can be found in the following locations in KDE:
There are several sections that appear in all KDE DocBook files, even though they are not required by DocBook itself:
<!ENTITY package "kde-module"> <!ENTITY % addindex "IGNORE"> <!ENTITY % English "INCLUDE">
<!-- TRANS:ROLES_OF_TRANSLATORS -->
authorgroupelement, and is a required placeholder for use in translation (also known as "i18n" from the number of letters between the first and the last of the word "internationalization").