diff --git a/en_US.ISO8859-1/books/fdp-primer/book.sgml b/en_US.ISO8859-1/books/fdp-primer/book.sgml index d26fde693a..26485ba9f9 100644 --- a/en_US.ISO8859-1/books/fdp-primer/book.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/book.sgml @@ -1,309 +1,271 @@ +%bookinfo; %authors; + +%teams; %mailing-lists; %man; %urls; %chapters; ]> FreeBSD Documentation Project Primer for New Contributors - - - Nik - Clayton - -
nik@FreeBSD.org
- - - + + The FreeBSD Documentation Project + 1998 1999 2000 2001 2002 2003 2004 - Nik Clayton + DocEng $FreeBSD$ $FreeBSD$ - - Redistribution and use in source (SGML DocBook) and 'compiled' - forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without - modification, are permitted provided that the following conditions are - met: - - - - Redistributions of source code (SGML DocBook) must retain the - above copyright notice, this list of conditions and the following - disclaimer as the first lines of this file unmodified. - - - - Redistributions in compiled form (transformed to other DTDs, - converted to PDF, PostScript, RTF and other formats) must - reproduce the above copyright notice, this list of conditions and - the following disclaimer in the documentation and/or other - materials provided with the distribution. - - - - - THIS DOCUMENTATION IS PROVIDED BY NIK CLAYTON "AS IS" AND ANY - EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR - PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL NIK CLAYTON BE LIABLE FOR - ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR - CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF - SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR - BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF - LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING - NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS - DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH - DAMAGE. - - - + &bookinfo.legalnotice; + Thank you for becoming a part of the FreeBSD Documentation Project. Your contribution is extremely valuable. This primer covers everything you will need to know in order to start contributing to the FreeBSD Documentation Project, from the tools and software you will be using (both mandatory and recommended) to the philosophy behind the Documentation Project. This document is a work in progress, and is not complete. Sections that are known to be incomplete are indicated with a * in their name. Preface Shell Prompts The following table shows the default system prompt and superuser prompt. The examples will use this prompt to indicate which user you should be running the example as. User Prompt Normal user &prompt.user; root &prompt.root; Typographic Conventions The following table describes the typographic conventions used in this book. Meaning Examples The name of commands, files, and directories. On screen computer output. Edit your .login file.Use ls -a to list all files.You have mail. What you type, when contrasted with on-screen computer output. &prompt.user; su Password: Manual page references. Use su 1 to change user names. User and group names Only root can do this. Emphasis You must do this. Command line variables; replace with the real name or variable. To delete a file, type rm filename Environment variables $HOME is your home directory. Notes, tips, important information, warnings, and examples Within the text appear notes, warnings, and examples. Notes are represented like this, and contain information that you should take note of, as it may affect what you do. Tips are represented like this, and contain information that you might find useful, or lead to an easier way to do something. Important information is represented like this. Typically they flag extra steps you may need to carry out. Warnings are represented like this, and contain information warning you about possible damage if you do not follow the instructions. This damage may be physical, to your hardware or to you, or it may be non-physical, such as the inadvertent deletion of important files. A sample example Examples are represented like this, and typically contain examples you should walk through, or show you what the results of a particular action should be. Acknowledgments My thanks to Sue Blake, Patrick Durusau, Jon Hamilton, Peter Flynn, and Christopher Maden, who took the time to read early drafts of this document and offer many valuable comments and criticisms. &chap.overview; &chap.tools; &chap.sgml-primer; &chap.sgml-markup; &chap.stylesheets; &chap.structure; &chap.doc-build; &chap.the-website; &chap.translations; &chap.writing-style; &chap.psgml-mode; &chap.see-also; &app.examples; diff --git a/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml b/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml index 4b53522b6b..37daa09b95 100644 --- a/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml @@ -1,2692 +1,2692 @@ SGML Markup This chapter describes the two markup languages you will encounter when you contribute to the FreeBSD documentation project. Each section describes the markup language, and details the markup that you are likely to want to use, or that is already in use. These markup languages contain a large number of elements, and it can be confusing sometimes to know which element to use for a particular situation. This section goes through the elements you are most likely to need, and gives examples of how you would use them. This is not an exhaustive list of elements, since that would just reiterate the documentation for each language. The aim of this section is to list those elements more likely to be useful to you. If you have a question about how best to markup a particular piece of content, please post it to the &a.doc;. Inline vs. block In the remainder of this document, when describing elements, inline means that the element can occur within a block element, and does not cause a line break. A block element, by comparison, will cause a line break (and other processing) when it is encountered. HTML HTML, the HyperText Markup Language, is the markup language of choice on the World Wide Web. More information can be found at <URL:>. HTML is used to markup pages on the FreeBSD web site. It should not (generally) be used to mark up other documentation, since DocBook offers a far richer set of elements to choose from. Consequently, you will normally only encounter HTML pages if you are writing for the web site. HTML has gone through a number of versions, 1, 2, 3.0, 3.2, and the latest, 4.0 (available in both strict and loose variants). The HTML DTDs are available from the ports collection in the textproc/html port. They are automatically installed as part of the textproc/docproj port. Formal Public Identifier (FPI) There are a number of HTML FPIs, depending upon the version (also known as the level) of HTML that you want to declare your document to be compliant with. The majority of HTML documents on the FreeBSD web site comply with the loose version of HTML 4.0. PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" Sectional elements An HTML document is normally split into two sections. The first section, called the head, contains meta-information about the document, such as its title, the name of the author, the parent document, and so on. The second section, the body, contains the content that will be displayed to the user. These sections are indicated with head and body elements respectively. These elements are contained within the top-level html element. Normal HTML document structure <html> <head> <title>The document's title</title> </head> <body> … </body> </html> Block elements Headings HTML allows you to denote headings in your document, at up to six different levels. The largest and most prominent heading is h1, then h2, continuing down to h6. The element's content is the text of the heading. <sgmltag>h1</sgmltag>, <sgmltag>h2</sgmltag>, etc. Use: First section

This is the heading for the first section

This is the heading for the first sub-section

This is the heading for the second section

]]> Generally, an HTML page should have one first level heading (h1). This can contain many second level headings (h2), which can in turn contain many third level headings. Each hn element should have the same element, but one further up the hierarchy, preceding it. Leaving gaps in the numbering is to be avoided. Bad ordering of <sgmltag>h<replaceable>n</replaceable></sgmltag> elements Use: First section

Sub-section

]]> Paragraphs HTML supports a single paragraph element, p. <sgmltag>p</sgmltag> Use: This is a paragraph. It can contain just about any other element.

]]> Block quotations A block quotation is an extended quotation from another document that should not appear within the current paragraph. <sgmltag>blockquote</sgmltag> Use: A small excerpt from the US Constitution:

We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
]]> Lists You can present the user with three types of lists, ordered, unordered, and definition. Typically, each entry in an ordered list will be numbered, while each entry in an unordered list will be preceded by a bullet point. Definition lists are composed of two sections for each entry. The first section is the term being defined, and the second section is the definition of the term. Ordered lists are indicated by the ol element, unordered lists by the ul element, and definition lists by the dl element. Ordered and unordered lists contain listitems, indicated by the li element. A listitem can contain textual content, or it may be further wrapped in one or more p elements. Definition lists contain definition terms (dt) and definition descriptions (dd). A definition term can only contain inline elements. A definition description can contain other block elements. <sgmltag>ul</sgmltag> and <sgmltag>ol</sgmltag> Use: An unordered list. Listitems will probably be preceded by bullets.

  • First item
  • Second item
  • Third item

An ordered list, with list items consisting of multiple paragraphs. Each item (note: not each paragraph) will be numbered.

  1. This is the first item. It only has one paragraph.

  2. This is the first paragraph of the second item.

    This is the second paragraph of the second item.

  3. This is the first and only paragraph of the third item.

]]> Definition lists with <sgmltag>dl</sgmltag> Use:
Term 1

Paragraph 1 of definition 1.

Paragraph 2 of definition 1.

Term 2

Paragraph 1 of definition 2.

Term 3
Paragraph 1 of definition 3. Note that the <p> element is not required in the single paragraph case.
]]> Pre-formatted text You can indicate that text should be shown to the user exactly as it is in the file. Typically, this means that the text is shown in a fixed font, multiple spaces are not merged into one, and line breaks in the text are significant. In order to do this, wrap the content in the pre element. <sgmltag>pre</sgmltag> You could use pre to mark up an e-mail message; From: nik@FreeBSD.org To: freebsd-doc@FreeBSD.org Subject: New documentation available There is a new copy of my primer for contributors to the FreeBSD Documentation Project available at Comments appreciated. N]]> Tables Most text-mode browsers (such as Lynx) do not render tables particularly effectively. If you are relying on the tabular display of your content, you should consider using alternative markup to prevent confusion. Mark up tabular information using the table element. A table consists of one or more table rows (tr), each containing one or more cells of table data (td). Each cell can contain other block elements, such as paragraphs or lists. It can also contain another table (this nesting can repeat indefinitely). If the cell only contains one paragraph then you do not need to include the p element. Simple use of <sgmltag>table</sgmltag> Use: This is a simple 2x2 table.

Top left cell Top right cell
Bottom left cell Bottom right cell
]]> A cell can span multiple rows and columns. To indicate this, add the rowspan and/or colspan attributes, with values indicating the number of rows of columns that should be spanned. Using <literal>rowspan</literal> Use: One tall thin cell on the left, two short cells next to it on the right.

Long and thin
Top cell Bottom cell
]]> Using <literal>colspan</literal> Use: One long cell on top, two short cells below it.

Top cell
Bottom left cell Bottom right cell
]]> Using <literal>rowspan</literal> and <literal>colspan</literal> together Use: On a 3x3 grid, the top left block is a 2x2 set of cells merged into one. The other cells are normal.

Top left large cell Top right cell
Middle right cell
Bottom left cell Bottom middle cell Bottom right cell
]]> In-line elements Emphasising information You have two levels of emphasis available in HTML, em and strong. em is for a normal level of emphasis and strong indicates stronger emphasis. Typically, em is rendered in italic and strong is rendered in bold. This is not always the case, however, and you should not rely on it. <sgmltag>em</sgmltag> and <sgmltag>strong</sgmltag> Use: This has been emphasised, while this has been strongly emphasised.

]]> Bold and italics Because HTML includes presentational markup, you can also indicate that particular content should be rendered in bold or italic. The elements are b and i respectively. <sgmltag>b</sgmltag> and <sgmltag>i</sgmltag> This is in bold, while this is in italics.

]]> Indicating fixed pitch text If you have content that should be rendered in a fixed pitch (typewriter) typeface, use tt (for teletype). <sgmltag>tt</sgmltag> Use: This document was originally written by Nik Clayton, who can be reached by e-mail as nik@FreeBSD.org.

]]> Content size You can indicate that content should be shown in a larger or smaller font. There are three ways of doing this. Use big and small around the content you wish to change size. These tags can be nested, so <big><big>This is much bigger</big></big> is possible. Use font with the size attribute set to +1 or -1 respectively. This has the same effect as using big or small. However, the use of this approach is deprecated. Use font with the size attribute set to a number between 1 and 7. The default font size is 3. This approach is deprecated. <sgmltag>big</sgmltag>, <sgmltag>small</sgmltag>, and <sgmltag>font</sgmltag> The following fragments all do the same thing. This text is slightly smaller. But this text is slightly bigger.

This text is slightly smaller. But this text is slightly bigger

This text is slightly smaller. But this text is slightly bigger.

]]> Links Links are also in-line elements. Linking to other documents on the WWW In order to include a link to another document on the WWW you must know the URL of the document you want to link to. The link is indicated with a, and the href attribute contains the URL of the target document. The content of the element becomes the link, and is normally indicated to the user in some way (underlining, change of color, different mouse cursor when over the link, and so on). Using <literal><a href="..."></literal> Use: More information is available at the FreeBSD web site.

]]> These links will take the user to the top of the chosen document. Linking to other parts of documents Linking to a point within another document (or within the same document) requires that the document author include anchors that you can link to. Anchors are indicated with a and the name attribute instead of href. Using <literal><a name="..."></literal> Use: This paragraph can be referenced in other links with the name para1.

]]> To link to a named part of a document, write a normal link to that document, but include the name of the anchor after a # symbol. Linking to a named part of another document Assume that the para1 example resides in a document called foo.html. More information can be found in the first paragraph of foo.html.

]]> If you are linking to a named anchor within the same document then you can omit the document's URL, and just include the name of the anchor (with the preceding #). Linking to a named part of the same document Assume that the para1 example resides in this document More information can be found in the first paragraph of this document.

]]> DocBook DocBook was originally developed by HaL Computer Systems and O'Reilly & Associates to be a DTD for writing technical documentation A short history can be found under http://www.oasis-open.org/committees/docbook/intro.shtml. . Since 1998 it is maintained by the DocBook Technical Committee. As such, and unlike LinuxDoc and HTML, DocBook is very heavily oriented towards markup that describes what something is, rather than describing how it should be presented. <literal>formal</literal> vs. <literal>informal</literal> Some elements may exist in two forms, formal and informal. Typically, the formal version of the element will consist of a title followed by the informal version of the element. The informal version will not have a title. The DocBook DTD is available from the ports collection in the textproc/docbook port. It is automatically installed as part of the textproc/docproj port. FreeBSD extensions The FreeBSD Documentation Project has extended the DocBook DTD by adding some new elements. These elements serve to make some of the markup more precise. Where a FreeBSD specific element is listed below it is clearly marked. Throughout the rest of this document, the term DocBook is used to mean the FreeBSD extended DocBook DTD. There is nothing about these extensions that is FreeBSD specific, it was just felt that they were useful enhancements for this particular project. Should anyone from any of the other *nix camps (NetBSD, OpenBSD, Linux, …) be interested in collaborating on a standard DocBook extension set, please get in - touch with &a.nik;. + touch with &a.doceng;. The FreeBSD extensions are not (currently) in the ports collection. They are stored in the FreeBSD CVS tree, as doc/share/sgml/freebsd.dtd. Formal Public Identifier (FPI) In compliance with the DocBook guidelines for writing FPIs for DocBook customisations, the FPI for the FreeBSD extended DocBook DTD is; PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" Document structure DocBook allows you to structure your documentation in several ways. In the FreeBSD Documentation Project we are using two primary types of DocBook document: the book and the article. A book is organized into chapters. This is a mandatory requirement. There may be parts between the book and the chapter to provide another layer of organisation. The Handbook is arranged in this way. A chapter may (or may not) contain one or more sections. These are indicated with the sect1 element. If a section contains another section then use the sect2 element, and so on, up to sect5. Chapters and sections contain the remainder of the content. An article is simpler than a book, and does not use chapters. Instead, the content of an article is organized into one or more sections, using the same sect1 (and sect2 and so on) elements that are used in books. Obviously, you should consider the nature of the documentation you are writing in order to decide whether it is best marked up as a book or an article. Articles are well suited to information that does not need to be broken down into several chapters, and that is, relatively speaking, quite short, at up to 20-25 pages of content. Books are best suited to information that can be broken up into several chapters, possibly with appendices and similar content as well. The FreeBSD tutorials are all marked up as articles, while this document, the FreeBSD FAQ, and the FreeBSD Handbook are all marked up as books. Starting a book The content of the book is contained within the book element. As well as containing structural markup, this element can contain elements that include additional information about the book. This is either meta-information, used for reference purposes, or additional content used to produce a title page. This additional information should be contained within bookinfo. Boilerplate <sgmltag>book</sgmltag> with <sgmltag>bookinfo</sgmltag> <book> <bookinfo> <title>Your title here</title> <author> <firstname>Your first name</firstname> <surname>Your surname</surname> <affiliation> <address><email>Your e-mail address</email></address> </affiliation> </author> <copyright> <year>1998</year> <holder role="mailto:your e-mail address">Your name</holder> </copyright> <releaseinfo>$FreeBSD$</releaseinfo> <abstract> <para>Include an abstract of the book's contents here.</para> </abstract> </bookinfo> … </book> Starting an article The content of the article is contained within the article element. As well as containing structural markup, this element can contain elements that include additional information about the article. This is either meta-information, used for reference purposes, or additional content used to produce a title page. This additional information should be contained within articleinfo. Boilerplate <sgmltag>article</sgmltag> with <sgmltag>articleinfo</sgmltag> <article> <articleinfo> <title>Your title here</title> <author> <firstname>Your first name</firstname> <surname>Your surname</surname> <affiliation> <address><email>Your e-mail address</email></address> </affiliation> </author> <copyright> <year>1998</year> <holder role="mailto:your e-mail address">Your name</holder> </copyright> <releaseinfo>$FreeBSD$</releaseinfo> <abstract> <para>Include an abstract of the article's contents here.</para> </abstract> </articleinfo> … </article> Indicating chapters Use chapter to mark up your chapters. Each chapter has a mandatory title. Articles do not contain chapters, they are reserved for books. A simple chapter The chapter's title ... ]]> A chapter cannot be empty; it must contain elements in addition to title. If you need to include an empty chapter then just use an empty paragraph. Empty chapters This is an empty chapter ]]> Sections below chapters In books, chapters may (but do not need to) be broken up into sections, subsections, and so on. In articles, sections are the main structural element, and each article must contain at least one section. Use the sectn element. The n indicates the section number, which identifies the section level. The first sectn is sect1. You can have one or more of these in a chapter. They can contain one or more sect2 elements, and so on, down to sect5. Sections in chapters A sample chapter Some text in the chapter. First section (1.1) … Second section (1.2) First sub-section (1.2.1) First sub-sub-section (1.2.1.1) … Second sub-section (1.2.2) … ]]> This example includes section numbers in the section titles. You should not do this in your documents. Adding the section numbers is carried out by the stylesheets (of which more later), and you do not need to manage them yourself. Subdividing using <sgmltag>part</sgmltag>s You can introduce another layer of organisation between book and chapter with one or more parts. This cannot be done in an article. Introduction Overview ... What is FreeBSD? ... History ... ]]> Block elements Paragraphs DocBook supports three types of paragraphs: formalpara, para, and simpara. Most of the time you will only need to use para. formalpara includes a title element, and simpara disallows some elements from within para. Stick with para. <sgmltag>para</sgmltag> Use: This is a paragraph. It can contain just about any other element. ]]> Appearance: This is a paragraph. It can contain just about any other element. Block quotations A block quotation is an extended quotation from another document that should not appear within the current paragraph. You will probably only need it infrequently. Blockquotes can optionally contain a title and an attribution (or they can be left untitled and unattributed). <sgmltag>blockquote</sgmltag> Use: A small excerpt from the US Constitution;
Preamble to the Constitution of the United States Copied from a web site somewhere We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
]]> Appearance:
Preamble to the Constitution of the United States Copied from a web site somewhere We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
Tips, notes, warnings, cautions, important information and sidebars. You may need to include extra information separate from the main body of the text. Typically this is meta information that the user should be aware of. Depending on the nature of the information, one of tip, note, warning, caution, and important should be used. Alternatively, if the information is related to the main text but is not one of the above, use sidebar. The circumstances in which to choose one of these elements over another is unclear. The DocBook documentation suggests; A Note is for information that should be heeded by all readers. An Important element is a variation on Note. A Caution is for information regarding possible data loss or software damage. A Warning is for information regarding possible hardware damage or injury to life or limb. <sgmltag>warning</sgmltag> Use: Installing FreeBSD may make you want to delete Windows from your hard disk. ]]> Installing FreeBSD may make you want to delete Windows from your hard disk. Lists and procedures You will often need to list pieces of information to the user, or present them with a number of steps that must be carried out in order to accomplish a particular goal. In order to do this, use itemizedlist, orderedlist, or procedureThere are other types of list element in DocBook, but we are not concerned with those at the moment. itemizedlist and orderedlist are similar to their counterparts in HTML, ul and ol. Each one consists of one or more listitem elements, and each listitem contains one or more block elements. The listitem elements are analogous to HTML's li tags. However, unlike HTML, they are required. procedure is slightly different. It consists of steps, which may in turn consists of more steps or substeps. Each step contains block elements. <sgmltag>itemizedlist</sgmltag>, <sgmltag>orderedlist</sgmltag>, and <sgmltag>procedure</sgmltag> Use: This is the first itemized item. This is the second itemized item. This is the first ordered item. This is the second ordered item. Do this. Then do this. And now do this. ]]> Appearance: This is the first itemized item. This is the second itemized item. This is the first ordered item. This is the second ordered item. Do this. Then do this. And now do this. Showing file samples If you want to show a fragment of a file (or perhaps a complete file) to the user, wrap it in the programlisting element. White space and line breaks within programlisting are significant. In particular, this means that the opening tag should appear on the same line as the first line of the output, and the closing tag should appear on the same line as the last line of the output, otherwise spurious blank lines may be included. <sgmltag>programlisting</sgmltag> Use: When you have finished, your program should look like this; #include <stdio.h> int main(void) { printf("hello, world\n"); }]]> Notice how the angle brackets in the #include line need to be referenced by their entities instead of being included literally. Appearance: When you have finished, your program should look like this; #include <stdio.h> int main(void) { printf("hello, world\n"); } Callouts A callout is a mechanism for referring back to an earlier piece of text or specific position within an earlier example without linking to it within the text. To do this, mark areas of interest in your example (programlisting, literallayout, or whatever) with the co element. Each element must have a unique id assigned to it. After the example include a calloutlist that refers back to the example and provides additional commentary. <sgmltag>co</sgmltag> and <sgmltag>calloutlist</sgmltag> When you have finished, your program should look like this; #include <stdio.h> int main(void) { printf("hello, world\n"); } Includes the standard IO header file. Specifies that main() returns an int. The printf() call that writes hello, world to standard output. ]]> Appearance: When you have finished, your program should look like this; #include <stdio.h> int main(void) { printf("hello, world\n"); } Includes the standard IO header file. Specifies that main() returns an int. The printf() call that writes hello, world to standard output. Tables Unlike HTML, you do not need to use tables for layout purposes, as the stylesheet handles those issues for you. Instead, just use tables for marking up tabular data. In general terms (and see the DocBook documentation for more detail) a table (which can be either formal or informal) consists of a table element. This contains at least one tgroup element, which specifies (as an attribute) the number of columns in this table group. Within the tablegroup you can then have one thead element, which contains elements for the table headings (column headings), and one tbody which contains the body of the table. Both tgroup and thead contain row elements, which in turn contain entry elements. Each entry element specifies one cell in the table. <sgmltag>informaltable</sgmltag> Use: This is column head 1 This is column head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 ]]> Appearance: This is column head 1 This is column head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 If you do not want a border around the table the frame attribute can be added to the informaltable element with a value of none (i.e., <informaltable frame="none">). Tables where <literal>frame="none"</literal> Appearance: This is column head 1 This is column head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 Examples for the user to follow A lot of the time you need to show examples for the user to follow. Typically, these will consist of dialogs with the computer; the user types in a command, the user gets a response back, they type in another command, and so on. A number of distinct elements and entities come into play here. screen Everything the user sees in this example will be on the computer screen, so the next element is screen. Within screen, white space is significant. prompt, &prompt.root; and &prompt.user; Some of the things the user will be seeing on the screen are prompts from the computer (either from the operating system, command shell, or application). These should be marked up using prompt. As a special case, the two shell prompts for the normal user and the root user have been provided as entities. Every time you want to indicate the user is at a shell prompt, use one of &prompt.root; and &prompt.user; as necessary. They do not need to be inside prompt. &prompt.root; and &prompt.user; are FreeBSD extensions to DocBook, and are not part of the original DTD. userinput When displaying text that the user should type in, wrap it in userinput tags. It will probably be displayed differently to the user. <sgmltag>screen</sgmltag>, <sgmltag>prompt</sgmltag>, and <sgmltag>userinput</sgmltag> Use: &prompt.user; ls -1 foo1 foo2 foo3 &prompt.user; ls -1 | grep foo2 foo2 &prompt.user; su Password: &prompt.root; cat foo2 This is the file called 'foo2']]> Appearance: &prompt.user; ls -1 foo1 foo2 foo3 &prompt.user; ls -1 | grep foo2 foo2 &prompt.user; su Password: &prompt.root; cat foo2 This is the file called 'foo2' Even though we are displaying the contents of the file foo2, it is not marked up as programlisting. Reserve programlisting for showing fragments of files outside the context of user actions. In-line elements Emphasising information When you want to emphasise a particular word or phrase, use emphasis. This may be presented as italic, or bold, or might be spoken differently with a text-to-speech system. There is no way to change the presentation of the emphasis within your document, no equivalent of HTML's b and i. If the information you are presenting is important then consider presenting it in important rather than emphasis. <sgmltag>emphasis</sgmltag> Use: FreeBSD is without doubt the premiere Unix like operating system for the Intel architecture.]]> Appearance: FreeBSD is without doubt the premiere Unix like operating system for the Intel architecture. Quotations To quote text from another document or source, or to denote a phrase that is used figuratively, use quote. Within a quote tag, you may use most of the markup tags available for normal text. Quotations Use: However, make sure that the search does not go beyond the boundary between local and public administration, as RFC 1535 calls it.]]> Appearance: However, make sure that the search does not go beyond the boundary between local and public administration, as RFC 1535 calls it. Keys, mouse buttons, and combinations To refer to a specific key on the keyboard, use keycap. To refer to a mouse button, use mousebutton. And to refer to combinations of key presses or mouse clicks, wrap them all in keycombo. keycombo has an attribute called action, which may be one of click, double-click, other, press, seq, or simul. The last two values denote whether the keys or buttons should be pressed in sequence, or simultaneously. The stylesheets automatically add any connecting symbols, such as +, between the key names, when wrapped in keycombo. Keys, mouse buttons, and combinations Use: To switch to the second virtual terminal, press Alt F1. To exit vi without saving your work, type Esc: q!. My window manager is configured so that Alt right mouse button is used to move windows.]]> Appearance: To switch to the second virtual terminal, press Alt F1. To exit vi without saving your work, type Esc: q!. My window manager is configured so that Alt right mouse button is used to move windows. Applications, commands, options, and cites You will frequently want to refer to both applications and commands when writing for the Handbook. The distinction between them is simple: an application is the name for a suite (or possibly just 1) of programs that fulfil a particular task. A command is the name of a program that the user can run. In addition, you will occasionally need to list one or more of the options that a command might take. Finally, you will often want to list a command with its manual section number, in the command(number) format so common in Unix manuals. Mark up application names with application. When you want to list a command with its manual section number (which should be most of the time) the DocBook element is citerefentry. This will contain a further two elements, refentrytitle and manvolnum. The content of refentrytitle is the name of the command, and the content of manvolnum is the manual page section. This can be cumbersome to write, and so a series of general entities have been created to make this easier. Each entity takes the form &man.manual-page.manual-section;. The file that contains these entities is in doc/share/sgml/man-refs.ent, and can be referred to using this FPI: PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN" Therefore, the introduction to your documentation will probably look like this: <!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ <!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> %man; … ]> Use command when you want to include a command name in-line but present it as something the user should type in. Use option to mark up a command's options. When referring to the same command multiple times in close proximity it is preferred to use the &man.command.section; notation to markup the first reference and use command to markup subsequent references. This makes the generated output, especially HTML, appear visually better. This can be confusing, and sometimes the choice is not always clear. Hopefully this example makes it clearer. Applications, commands, and options. Use: Sendmail is the most widely used Unix mail application. Sendmail includes the sendmail 8 , &man.mailq.8;, and &man.newaliases.8; programs. One of the command line parameters to sendmail 8 , , will display the current status of messages in the mail queue. Check this on the command line by running sendmail -bp.]]> Appearance: Sendmail is the most widely used Unix mail application. Sendmail includes the sendmail 8 , mailq 8 , and newaliases 8 programs. One of the command line parameters to sendmail 8 , , will display the current status of messages in the mail queue. Check this on the command line by running sendmail -bp. Notice how the &man.command.section; notation is easier to follow. Files, directories, extensions Whenever you wish to refer to the name of a file, a directory, or a file extension, use filename. <sgmltag>filename</sgmltag> Use: The SGML source for the Handbook in English can be found in /usr/doc/en/handbook/. The first file is called handbook.sgml in that directory. You should also see a Makefile and a number of files with a .ent extension.]]> Appearance: The SGML source for the Handbook in English can be found in /usr/doc/en/handbook/. The first file is called handbook.sgml in that directory. You should also see a Makefile and a number of files with a .ent extension. The name of ports FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. You might need to include the name of a program from the FreeBSD Ports Collection in the documentation. Use the filename tag with the role attribute set to package to identify these. Since ports can be installed in any number of locations, only include the category and the port name; do not include /usr/ports. <sgmltag>filename</sgmltag> tag with <literal>package</literal> role Use: Install the net/ethereal port to view network traffic.]]> Appearance: Install the net/ethereal port to view network traffic. Devices FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. When referring to devices you have two choices. You can either refer to the device as it appears in /dev, or you can use the name of the device as it appears in the kernel. For this latter course, use devicename. Sometimes you will not have a choice. Some devices, such as networking cards, do not have entries in /dev, or the entries are markedly different from those entries. <sgmltag>devicename</sgmltag> Use: sio is used for serial communication in FreeBSD. sio manifests through a number of entries in /dev, including /dev/ttyd0 and /dev/cuaa0. By contrast, the networking devices, such as ed0 do not appear in /dev. In MS-DOS, the first floppy drive is referred to as a:. In FreeBSD it is /dev/fd0.]]> Appearance: sio is used for serial communication in FreeBSD. sio manifests through a number of entries in /dev, including /dev/ttyd0 and /dev/cuaa0. By contrast, the networking devices, such as ed0 do not appear in /dev. In MS-DOS, the first floppy drive is referred to as a:. In FreeBSD it is /dev/fd0. Hosts, domains, IP addresses, and so forth FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. You can markup identification information for networked computers (hosts) in several ways, depending on the nature of the information. All of them use hostid as the element, with the role attribute selecting the type of the marked up information. No role attribute, or role="hostname" With no role attribute (i.e., hostid.../hostid) the marked up information is the simple hostname, such as freefall or wcarchive. You can explicitly specify this with role="hostname". role="domainname" The text is a domain name, such as FreeBSD.org or ngo.org.uk. There is no hostname component. role="fqdn" The text is a Fully Qualified Domain Name, with both hostname and domain name parts. role="ipaddr" The text is an IP address, probably expressed as a dotted quad. role="ip6addr" The text is an IPv6 address. role="netmask" The text is a network mask, which might be expressed as a dotted quad, a hexadecimal string, or as a / followed by a number. role="mac" The text is an Ethernet MAC address, expressed as a series of 2 digit hexadecimal numbers separated by colons. <sgmltag>hostid</sgmltag> and roles Use: The local machine can always be referred to by the name localhost, which will have the IP address 127.0.0.1. The FreeBSD.org domain contains a number of different hosts, including freefall.FreeBSD.org and bento.FreeBSD.org. When adding an IP alias to an interface (using ifconfig) always use a netmask of 255.255.255.255 (which can also be expressed as 0xffffffff. The MAC address uniquely identifies every network card in existence. A typical MAC address looks like 08:00:20:87:ef:d0.]]> Appearance: The local machine can always be referred to by the name localhost, which will have the IP address 127.0.0.1. The FreeBSD.org domain contains a number of different hosts, including freefall.FreeBSD.org and bento.FreeBSD.org. When adding an IP alias to an interface (using ifconfig) always use a netmask of 255.255.255.255 (which can also be expressed as 0xffffffff. The MAC address uniquely identifies every network card in existence. A typical MAC address looks like 08:00:20:87:ef:d0. Usernames FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. When you need to refer to a specific username, such as root or bin, use username. <sgmltag>username</sgmltag> Use: To carry out most system administration functions you will need to be root.]]> Appearance: To carry out most system administration functions you will need to be root. Describing <filename>Makefile</filename>s FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. Two elements exist to describe parts of Makefiles, maketarget and makevar. maketarget identifies a build target exported by a Makefile that can be given as a parameter to make. makevar identifies a variable that can be set (in the environment, on the make command line, or within the Makefile) to influence the process. <sgmltag>maketarget</sgmltag> and <sgmltag>makevar</sgmltag> Use: Two common targets in a Makefile are all and clean. Typically, invoking all will rebuild the application, and invoking clean will remove the temporary files (.o for example) created by the build process. clean may be controlled by a number of variables, including CLOBBER and RECURSE.]]> Appearance: Two common targets in a Makefile are all and clean. Typically, invoking all will rebuild the application, and invoking clean will remove the temporary files (.o for example) created by the build process. clean may be controlled by a number of variables, including CLOBBER and RECURSE. Literal text You will often need to include literal text in the Handbook. This is text that is excerpted from another file, or which should be copied from the Handbook into another file verbatim. Some of the time, programlisting will be sufficient to denote this text. programlisting is not always appropriate, particularly when you want to include a portion of a file in-line with the rest of the paragraph. On these occasions, use literal. <sgmltag>literal</sgmltag> Use: The maxusers 10 line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support.]]> Appearance: The maxusers 10 line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support. Showing items that the user <emphasis>must</emphasis> fill in There will often be times when you want to show the user what to do, or refer to a file, or command line, or similar, where the user cannot simply copy the examples that you provide, but must instead include some information themselves. replaceable is designed for this eventuality. Use it inside other elements to indicate parts of that element's content that the user must replace. <sgmltag>replaceable</sgmltag> Use: &prompt.user; man command ]]> Appearance: &prompt.user; man command replaceable can be used in many different elements, including literal. This example also shows that replaceable should only be wrapped around the content that the user is meant to provide. The other content should be left alone. Use: The maxusers n line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support. For a desktop workstation, 32 is a good value for n.]]> Appearance: The maxusers n line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support. For a desktop workstation, 32 is a good value for n. Quoting system errors You might want to show errors generated by FreeBSD. Mark these with errorname. This indicates the exact error that appears. <sgmltag>errorname</sgmltag> Use: Panic: cannot mount root ]]> Appearance: Panic: cannot mount root Images Image support in the documentation is currently extremely experimental. I think the mechanisms described here are unlikely to change, but that is not guaranteed. You will also need to install the graphics/ImageMagick port, which is used to convert between the different image formats. This is a big port, and most of it is not required. However, while we are working on the Makefiles and other infrastructure it makes things easier. This port is not in the textproc/docproj meta port, you must install it by hand. The best example of what follows in practice is the doc/en_US.ISO8859-1/articles/vm-design/ document. If you are unsure of the description that follows, take a look at the files in that directory to see how everything hangs together. Experiment with creating different formatted versions of the document to see how the image markup appears in the formatted output. Image formats We currently support two formats for images. The format you should use will depend on the nature of your image. For images that are primarily vector based, such as network diagrams, time lines, and similar, use Encapsulated Postscript, and make sure that your images have the .eps extension. For bitmaps, such as screen captures, use the Portable Network Graphic format, and make sure that your images have the .png extension. These are the only formats in which images should be committed to the CVS repository. Use the right format for the right image. It is to be expected that your documentation will have a mix of EPS and PNG images. The Makefiles ensure that the correct format image is chosen depending on the output format that you use for your documentation. Do not commit the same image to the repository in two different formats. It is anticipated that the Documentation Project will switch to using the Scalable Vector Graphic (SVG) format for vector images. However, the current state of SVG capable editing tools makes this impractical. Markup The markup for an image is relatively simple. First, markup a mediaobject. The mediaobject can contain other, more specific objects. We are concerned with two, the imageobject and the textobject. You should include one imageobject, and two textobject elements. The imageobject will point to the name of the image file that will be used (without the extension). The textobject elements contain information that will be presented to the user as well as, or instead of, the image. There are two circumstances where this can happen. When the reader is viewing the documentation in HTML. In this case, each image will need to have associated alternate text to show the user, typically whilst the image is loading, or if they hover the mouse pointer over the image. When the reader is viewing the documentation in plain text. In this case, each image should have an ASCII art equivalent to show the user. An example will probably make things easier to understand. Suppose you have an image, called fig1, that you want to include in the document. This image is of a rectangle with an A inside it. The markup for this would be as follows. <mediaobject> <imageobject> <imagedata fileref="fig1"> </imageobject> <textobject> <literallayout class="monospaced">+---------------+ | A | +---------------+</literallayout> </textobject> <textobject> <phrase>A picture</phrase> </textobject> </mediaobject> Include an imagedata element inside the imageobject element. The fileref attribute should contain the filename of the image to include, without the extension. The stylesheets will work out which extension should be added to the filename automatically. The first textobject should contain a literallayout element, where the class attribute is set to monospaced. This is your opportunity to demonstrate your ASCII art skills. This content will be used if the document is converted to plain text. Notice how the first and last lines of the content of the literallayout element butt up next to the element's tags. This ensures no extraneous white space is included. The second textobject should contain a single phrase element. The contents of this will become the alt attribute for the image when this document is converted to HTML. <filename>Makefile</filename> entries Your images must be listed in the Makefile in the IMAGES variable. This variable should contain the name of all your source images. For example, if you have created three figures, fig1.eps, fig2.png, fig3.png, then your Makefile should have lines like this in it. … IMAGES= fig1.eps fig2.png fig3.png … or … IMAGES= fig1.eps IMAGES+= fig2.png IMAGES+= fig3.png … Again, the Makefile will work out the complete list of images it needs to build your source document, you only need to list the image files you provided. Images and chapters in subdirectories You must be careful when you separate your documentation into smaller files (see ) in different directories. Suppose you have a book with three chapters, and the chapters are stored in their own directories, called chapter1/chapter.sgml, chapter2/chapter.sgml, and chapter3/chapter.sgml. If each chapter has images associated with it, I suggest you place those images in each chapter's subdirectory (chapter1/, chapter2/, and chapter3/). However, if you do this you must include the directory names in the IMAGES variable in the Makefile, and you must include the directory name in the imagedata element in your document. For example, if you have chapter1/fig1.png, then chapter1/chapter.sgml should contain <mediaobject> <imageobject> <imagedata fileref="chapter1/fig1"> </imageobject> … </mediaobject> The directory name must be included in the fileref attribute The Makefile must contain … IMAGES= chapter1/fig1.png … Then everything should just work. Links Links are also in-line elements. Linking to other parts of the same document Linking within the same document requires you to specify where you are linking from (i.e., the text the user will click, or otherwise indicate, as the source of the link) and where you are linking to (the link's destination). Each element within DocBook has an attribute called id. You can place text in this attribute to uniquely name the element it is attached to. This value will be used when you specify the link source. Normally, you will only be linking to chapters or sections, so you would add the id attribute to these elements. <literal>id on chapters and sections</literal> Introduction This is the introduction. It contains a subsection, which is identified as well. Sub-sect 1 This is the subsection. ]]> Obviously, you should use more descriptive values. The values must be unique within the document (i.e., not just the file, but the document the file might be included in as well). Notice how the id for the subsection is constructed by appending text to the id of the chapter. This helps to ensure that they are unique. If you want to allow the user to jump into a specific portion of the document (possibly in the middle of a paragraph or an example), use anchor. This element has no content, but takes an id attribute. <sgmltag>anchor</sgmltag> This paragraph has an embedded link target in it. It will not show up in the document.]]> When you want to provide the user with a link they can activate (probably by clicking) to go to a section of the document that has an id attribute, you can use either xref or link. Both of these elements have a linkend attribute. The value of this attribute should be the value that you have used in a id attribute (it does not matter if that value has not yet occurred in your document; this will work for forward links as well as backward links). If you use xref then you have no control over the text of the link. It will be generated for you. Using <sgmltag>xref</sgmltag> Assume that this fragment appears somewhere in a document that includes the id example; More information can be found in . More specific information can be found in .]]> The text of the link will be generated automatically, and will look like (emphasised text indicates the text that will be the link);
More information can be found in Chapter One. More specific information can be found in the section called Sub-sect 1.
Notice how the text from the link is derived from the section title or the chapter number. This means that you cannot use xref to link to an id attribute on an anchor element. The anchor has no content, so the xref cannot generate the text for the link. If you want to control the text of the link then use link. This element wraps content, and the content will be used for the link. Using <sgmltag>link</sgmltag> Assume that this fragment appears somewhere in a document that includes the id example. More information can be found in the first chapter. More specific information can be found in this section.]]> This will generate the following (emphasised text indicates the text that will be the link);
More information can be found in the first chapter. More specific information can be found in this section.
That last one is a bad example. Never use words like this or here as the source for the link. The reader will need to hunt around the surrounding context to see where the link is actually taking them. You can use link to include a link to an id on an anchor element, since the link content defines the text that will be used for the link. Linking to documents on the WWW Linking to external documents is much simpler, as long as you know the URL of the document you want to link to. Use ulink. The url attribute is the URL of the page that the link points to, and the content of the element is the text that will be displayed for the user to activate. <sgmltag>ulink</sgmltag> Use: Of course, you could stop reading this document and go to the FreeBSD home page instead.]]> Appearance: Of course, you could stop reading this document and go to the FreeBSD home page instead. diff --git a/en_US.ISO8859-1/books/fdp-primer/tools/chapter.sgml b/en_US.ISO8859-1/books/fdp-primer/tools/chapter.sgml index d13b4f387d..a9490faf3d 100644 --- a/en_US.ISO8859-1/books/fdp-primer/tools/chapter.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/tools/chapter.sgml @@ -1,291 +1,291 @@ Tools The FDP uses a number of different software tools to help manage the FreeBSD documentation, convert it to different output formats, and so on. You will need to use these tools yourself if you are to work with the FreeBSD documentation. All these tools are available as FreeBSD Ports and Packages, greatly simplifying the work you have to do to install them. You will need to install these tools before you work through any of the examples in later chapters. The actual usage of these tools is covered in later chapters. Use <filename role="package">textproc/docproj</filename> if possible You can save yourself a lot of time if you install the textproc/docproj port. This is a meta-port which does not contain any software itself. Instead, it depends on various other ports being installed correctly. Installing this port should automatically download and install all of the packages listed in this chapter that you need. One of the packages that you might need is the JadeTeX macro set. In turn, this macro set requires TeX to be installed. TeX is a large package, and you only need it if you want to produce Postscript or PDF output. To save yourself time and space you must specify whether or not you want JadeTeX (and therefore TeX) installed when you install this port. Either do: &prompt.root; make JADETEX=yes install or &prompt.root; make JADETEX=no install as necessary. Alternatively you may install textproc/docproj-jadetex or textproc/docproj-nojadetex. These slave ports define the JADETEX variable for you, therefore they will install the same suite of applications on your machine. Note that you can produce only HTML or ASCII text output if you do not install JadeTeX. PostScript or PDF output require TeX. Mandatory tools Software These programs are required before you can usefully work with the FreeBSD documentation, and they will allow you to convert the documentation to HTML, plain text, and RTF formats. They are all included in textproc/docproj. SP (textproc/sp) A suite of applications, including a validating SGML parser, and an SGML normaliser. Jade (textproc/jade) A DSSSL implementation. Used for converting marked up documents to other formats, including HTML and TeX. Tidy (www/tidy) An HTML 'pretty printer', used to reformat some of the automatically generated HTML so that it is easier to follow. Links (www/links) A text-mode WWW browser that can also convert HTML files to plain text. peps (graphics/peps) Some of the documentation includes images, some of which are stored as EPS files. These must be converted to PNG before most web browsers will display them. DTDs and Entities These are the DTDs and entity sets used by the FDP. They need to be installed before you can work with any of the documentation. HTML DTD (textproc/html) HTML is the markup language of choice for the World Wide Web, and is used throughout the FreeBSD web site. DocBook DTD (textproc/docbook) DocBook is designed for marking up technical documentation. All the FreeBSD documentation is written in DocBook. ISO 8879 entities (textproc/iso8879) 19 of the ISO 8879:1986 character entity sets used by many DTDs. Includes named mathematical symbols, additional characters in the 'Latin' character set (accents, diacriticals, and so on), and Greek symbols. Stylesheets The stylesheets are used when converting and formatting the documentation for display on screen, printing, and so on. Modular DocBook Stylesheets (textproc/dsssl-docbook-modular) The Modular DocBook Stylesheets are used when converting documentation marked up in DocBook to other formats, such as HTML or RTF. Optional tools You do not need to have any of the following installed. However, you may find it easier to work with the documentation if you do, and they may give you more flexibility in the output formats that can be generated. Software JadeTeX and teTeX (print/jadetex and print/teTeX) Jade and teTeX are used to convert DocBook documents to DVI, Postscript, and PDF formats. The JadeTeX macros are needed in order to do this. If you do not intend to convert your documentation to one of these formats (i.e., HTML, plain text, and RTF are sufficient) then you do not need to install JadeTeX and teTeX. This can be a significant space and time saver, as teTeX is over 30MB in size. If you decide to install JadeTeX and teTeX then you will need to configure teTeX after JadeTeX has been installed. print/jadetex/pkg-message contains detailed instructions explaining what you need to do. Emacs or XEmacs (editors/emacs or editors/xemacs) Both these editors include a special mode for editing documents marked up according to an SGML DTD. This mode includes commands to reduce the amount of typing you need, and help reduce the possibility of errors. You do not need to use them; any text editor can be used to edit marked up documents. You may find they make you more efficient. If anyone has recommendations for other software that is useful - when manipulating SGML documents, please let &a.nik; know, so they + when manipulating SGML documents, please let &a.doceng; know, so they can be added to this list. diff --git a/en_US.ISO8859-1/books/fdp-primer/translations/chapter.sgml b/en_US.ISO8859-1/books/fdp-primer/translations/chapter.sgml index 6b5e19e063..28f76af819 100644 --- a/en_US.ISO8859-1/books/fdp-primer/translations/chapter.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/translations/chapter.sgml @@ -1,457 +1,457 @@ Translations This is the FAQ for people translating the FreeBSD documentation (FAQ, Handbook, tutorials, manual pages, and others) to different languages. It is very heavily based on the translation FAQ from the FreeBSD German Documentation Project, originally written by Frank Gründer elwood@mc5sys.in-berlin.de and translated back to English by Bernd Warken bwarken@mayn.de. - The FAQ maintainer is &a.nik;. + The FAQ is mainted by the &a.doceng;. Why a FAQ? More and more people are approaching the freebsd-doc mailing list and volunteering to translate FreeBSD documentation to other languages. This FAQ aims to answer their questions so they can start translating documentation as quickly as possible. What do i18n and l10n mean? i18n means internationalisation and l10n means localisation. They are just a convenient shorthand. i18n can be read as i followed by 18 letters, followed by n. Similarly, l10n is l followed by 10 letters, followed by n. Is there a mailing list for translators? Yes. Different translation groups have their own mailing lists. The list of translation projects has more information about the mailing lists and web sites run by each translation project. Are more translators needed? Yes. The more people work on translation the faster it gets done, and the faster changes to the English documentation are mirrored in the translated documents. You do not have to be a professional translator to be able to help. What languages do I need to know? Ideally, you will have a good knowledge of written English, and obviously you will need to be fluent in the language you are translating to. English is not strictly necessary. For example, you could do a Hungarian translation of the FAQ from the Spanish translation. What software do I need to know? It is strongly recommended that you maintain a local copy of the FreeBSD CVS repository (at least the documentation part) either using CTM or CVSup. The "Staying current with FreeBSD" chapter in the Handbook explains how to use these applications. You should be comfortable using CVS. This will allow you to see what has changed between different versions of the files that make up the documentation. [XXX To Do -- write a tutorial that shows how to use CVSup to get just the documentation, check it out, and see what has changed between two arbitrary revisions] How do I find out who else might be translating to the same language? The Documentation Project translations page lists the translation efforts that are currently known about. If others are already working on translating documentation to your language, please do not duplicate their efforts. Instead, contact them to see how you can help. If no one is listed on that page as translating for your language, then send a message to the &a.doc; in case someone else is thinking of doing a translation, but has not announced it yet. No one else is translating to my language. What do I do? Congratulations, you have just started the FreeBSD your-language-here Documentation Translation Project. Welcome aboard. First, decide whether or not you have got the time to spare. Since you are the only person working on your language at the moment it is going to be your responsibility to publicise your work and coordinate any volunteers that might want to help you. Write an e-mail to the Documentation Project mailing list, announcing that you are going to translate the documentation, so the Documentation Project translations page can be maintained. If there is already someone in your country providing FreeBSD mirroring services you should contact them and ask if you can have some webspace for your project, and possibly an e-mail address or mailing list services. Then pick a document and start translating. It is best to start with something fairly small—either the FAQ, or one of the tutorials. I have translated some documentation, where do I send it? That depends. If you are already working with a translation team (such as the Japanese team, or the German team) then they will have their own procedures for handling submitted documentation, and these will be outlined on their web pages. If you are the only person working on a particular language (or you are responsible for a translation project and want to submit your changes back to the FreeBSD project) then you should send your translation to the FreeBSD project (see the next question). I am the only person working on translating to this language, how do I submit my translation? or We are a translation team, and want to submit documentation that our members have translated for us? First, make sure your translation is organized properly. This means that it should drop into the existing documentation tree and build straight away. Currently, the FreeBSD documentation is stored in a top level directory called doc/. Directories below this are named according to the language code they are written in, as defined in ISO639 (/usr/share/misc/iso639 on a version of FreeBSD newer than 20th January 1999). If your language can be encoded in different ways (for example, Chinese) then there should be directories below this, one for each encoding format you have provided. Finally, you should have directories for each document. For example, a hypothetical Swedish translation might look like doc/ sv_SE.ISO8859-1/ Makefile books/ faq/ Makefile book.sgml sv_SE.ISO8859-1 is the name of the translation, in lang.encoding form. Note the two Makefiles, which will be used to build the documentation. Use &man.tar.1; and &man.gzip.1; to compress up your documentation, and send it to the project. &prompt.user; cd doc &prompt.user; tar cf swedish-docs.tar sv &prompt.user; gzip -9 swedish-docs.tar Put swedish-docs.tar.gz somewhere. If you do not have access to your own webspace (perhaps your ISP does not - let you have any) then you can e-mail &a.nik;, and arrange to e-mail + let you have any) then you can e-mail &a.doceng;, and arrange to e-mail the files when it is convenient. Either way, you should use &man.send-pr.1; to submit a report indicating that you have submitted the documentation. It would be very helpful if you could get other people to look over your translation and double check it first, since it is unlikely that the person committing it will be fluent in the language. Someone (probably the Documentation Project Manager, currently - &a.nik;) will then take your translation and confirm that it builds. + &a.doceng;) will then take your translation and confirm that it builds. In particular, the following things will be looked at: Do all your files use RCS strings (such as "ID")? Does make all in the sv_SE.ISO8859-1 directory work correctly? Does make install work correctly? If there are any problems then whoever is looking at the submission will get back to you to work them out. If there are no problems your translation will be committed as soon as possible. Can I include language or country specific text in my translation? We would prefer that you did not. For example, suppose that you are translating the Handbook to Korean, and want to include a section about retailers in Korea in your Handbook. There is no real reason why that information should not be in the English (or German, or Spanish, or Japanese, or …) versions as well. It is feasible that an English speaker in Korea might try and pick up a copy of FreeBSD whilst over there. It also helps increase FreeBSD's perceived presence around the globe, which is not a bad thing. If you have country specific information, please submit it as a change to the English Handbook (using &man.send-pr.1;) and then translate the change back to your language in the translated Handbook. Thanks. How should language specific characters be included? Non-ASCII characters in the documentation should be included using SGML entities. Briefly, these look like an ampersand (&), the name of the entity, and a semi-colon (;). The entity names are defined in ISO8879, which is in the ports tree as textproc/iso8879. A few examples include Entity Appearance Description &eacute; é Small e with an acute accent &Eacute; É Large E with an acute accent &uuml; ü Small u with an umlaut After you have installed the iso8879 port, the files in /usr/local/share/sgml/iso8879 contain the complete list. Addressing the reader In the English documents, the reader is addressed as you, there is no formal/informal distinction as there is in some languages. If you are translating to a language which does distinguish, use whichever form is typically used in other technical documentation in your language. If in doubt, use a mildly polite form. Do I need to include any additional information in my translations? Yes. The header of the English version of each document will look something like this; <!-- The FreeBSD Documentation Project $FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/translations/chapter.sgml,v 1.5 2000/07/07 18:38:38 dannyboy Exp $ --> The exact boilerplate may change, but it will always include a $FreeBSD$ line and the phrase The FreeBSD Documentation Project. Note that the $FreeBSD part is expanded automatically by CVS, so it should be empty (just $FreeBSD$) for new files. Your translated documents should include their own $FreeBSD$ line, and change the FreeBSD Documentation Project line to The FreeBSD language Documentation Project. In addition, you should add a third line which indicates which revision of the English text this is based on. So, the Spanish version of this file might start <!-- The FreeBSD Spanish Documentation Project $FreeBSD: doc/es_ES.ISO8859-1/books/fdp-primer/translations/chapter.sgml,v 1.3 1999/06/24 19:12:32 jesusr Exp $ Original revision: 1.11 -->