Index: chapter.sgml =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml,v retrieving revision 1.48 diff -u -r1.48 chapter.sgml --- chapter.sgml 12 Sep 2005 16:47:36 -0000 1.48 +++ chapter.sgml 26 Dec 2008 01:51:16 -0000 @@ -31,7 +31,7 @@ --> - Writing style + Writing Style In order to promote consistency between the myriad authors of the FreeBSD documentation, some guidelines have been drawn up for authors to @@ -39,7 +39,7 @@ - Use American English spelling + Use American English Spelling There are several variants of English, with different spellings @@ -166,16 +166,16 @@ Style, by William Strunk. - Style guide + Style Guide - To keep the source for the Handbook consistent when many different + To keep the source for the documentation consistent when many different people are editing it, please follow these style conventions. - Letter case + Letter Case - Tags are entered in lower case, <para>, - not <PARA>. + Tags are entered in lower case, para, + not PARA. Text that appears in SGML contexts is generally written in upper case, <!ENTITY…>, and @@ -188,16 +188,16 @@ Acronyms Acronyms should generally be spelled out the first time - they appear in a book, as in: "Network Time Protocol (NTP)." After the + they appear in a document, as in: Network Time Protocol (NTP). After the acronym has been defined, you should generally use the acronym only (not the whole term, unless it makes more sense contextually to use the whole term). Usually, acronyms are - defined only one per book. But if you prefer, you can also + defined only one per document. But if you prefer, you can also define them the first time they appear in each chapter. The first three uses of an acronym should be enclosed in - <acronym> tags, with a role attribute + acronym tags, with a role attribute with the full term defined. This allows a link to the glossary to be created, and for mouseovers to be rendered with the fully expanded term. @@ -263,10 +263,10 @@ - Tag style + Tag Style - Tag spacing + Tag Spacing Tags that start at the same indent as a previous tag should be separated by a blank line, and those that are not @@ -302,7 +302,7 @@ - Separating tags + Separating Tags Tags like itemizedlist which will always have further tags inside them, and in fact do not take @@ -332,13 +332,13 @@ - White space changes + White Space Changes When committing changes, do not commit changes to the content at the same time as changes to the formatting. - This is so that the teams that convert the Handbook to other + This is so that the teams that convert the documentation to other languages can quickly see what content has actually changed in your commit, without having to decide whether a line has changed because of the content, or just because it has been refilled. @@ -352,7 +352,7 @@ - Nonbreaking space + Non-Breaking Space Avoid line breaks in places where they look ugly or make it difficult to follow a sentence. Line breaks depend @@ -364,7 +364,7 @@ GB. Hardware compression … The general entity &nbsp; prohibits - line breaks between parts belonging together. Use nonbreaking + line breaks between parts belonging together. Use non-breaking spaces in the following places: @@ -389,7 +389,7 @@ - Word list + Word List The following is a small list of words spelled the way they should be used in the FreeBSD Documentation Project. If the