From cf43250f83a3ce2c191cab49623fb1382bd9c3dc Mon Sep 17 00:00:00 2001 From: Gabor Pali Date: Wed, 21 Jan 2009 23:49:33 +0000 Subject: [PATCH] - Fix capitalization - Eliminate reference to books for generalization ("document") - Use where applicable - Mark up quotes with - Fix spelling of "non-breaking" --- .../fdp-primer/writing-style/chapter.sgml | 38 +++++++++---------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml b/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml index d6f8a670d3..6e8831fbc6 100644 --- a/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml @@ -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 @@ augroup END - 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 @@ augroup END - 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 @@ augroup END - 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 @@ augroup END - 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 @@ augroup END 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 @@ GB. Hardware compression … - 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