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 95c9cb768b..127ca29246 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
@@ -1,340 +1,340 @@
Writing style
In order to promote consistency between the myriad authors of the
FreeBSD documentation, some guidelines have been drawn up for authors to
follow.
Do not use contractions
Do not use contractions. Always spell the phrase out in full.
“Don't use contractions” would be wrong.
Avoiding contractions makes for a more formal tone, is more
precise, and slightly easier for translators.
Use the serial comma
In a list of items within a paragraph, seperate each item from
the others with a comma. Seperate the last item from the others with
a comma and the word “and”.
For example, look at the following quote;
This is a list of one, two and three items.
Is this a list of three items, “one”,
“two”, and “three”, or a list of two items,
“one” and “two and three”?
It is better to be explicit and include a serial comma;
This is a list of one, two, and three items.
Avoid redundant phrases
Try not to use redundant phrases. In particular, “the
command”, “the file”, and “man
command” are probably redundant.
These two examples show this for commands. The second example
is preferred.
Use the command cvsup to update your
sources
Use cvsup to update your sources
These two examples show this for filenames. The second example
is preferred.
… in the filename
/etc/rc.local…
… in
/etc/rc.local…
These two examples show this for manual references. The second
example is preferred (the second example uses
citerefentry).
See man csh for more
information.
See &man.csh.1;
Two spaces at the end of sentences
Always use two spaces at the end of sentences, as this
improves readability, and eases use of tools such as
emacs.
While it may be argued that a capital letter following
the end of sentence period, this is not the case, especially
in name usage. Jordan K. Hubbard
is a good
example; it has a capital H following a
period and a space, and there certainly isn't a new sentence
there.
For more information about writing style, see Elements of
Style, by William Strunk.
Style guide
To keep the source for the Handbook consistent when many different
people are editing it, please follow these style conventions.
Letter case
Tags are entered in lower case, <para>,
not <PARA>.
Text that appears in SGML contexts is generally written in upper
case, <!ENTITY…>, and
<!DOCTYPE…>, not
<!entity…> and
<!doctype…>.
Indentation
Each file starts with indentation set at column 0,
regardless of the indentation level of the file
which might contain this one.
Every start tag increases the indentation level by 2 spaces, and
every end tag decreases the indentation level by 2 spaces. Content
within elements should be indented by two spaces if the content runs
over more than one line.
For example, the source for this section looks something
like:
...
...
Indentation
Each file starts with indentation set at column 0,
regardless of the indentation level of the file
which might contain this one.
Every start tag increases the indentation level by 2 spaces, and
every end tag decreases the indentation level by 2 spaces. Content
within elements should be indented by two spaces if the content runs
over more than one line.
...
]]>
If you use Emacs or
Xemacs to edit the files then
sgml-mode should be loaded automatically, and the
Emacs local variables at the bottom of each file should enforce these
styles.
Tag style
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
at the same indent as a previous tag should not:
NIS
October 1999
...
...
...
...
...
...
...
]]>
Special tags
Some tags just don't follow the indenting rules of the
previous section; screen and
programlisting should always be
left-aligned.
…
]]>
informalexample also should be
left-aligned when it wraps a screen or
programlisting.
These examples should be separated from the rest of the
content by a blank line before and after.
Separating tags
Tags like itemizedlist which will
always have further tags inside them, and in fact don't take
character data themselves, are always on a line by
themselves.
Tags like para and
term don't need other tags to contain
normal character data, and their contents begin immediately
after the tag, on the same line.
The same applies to when these two types of tags
close.
This leads to an obvious problem when mixing these
tags.
When a starting tag which cannot contain character data
directly follows a tag of the type that requires other tags
within it to use character data, they are on separate lines.
The second tag should be properly indented.
When a tag which can contain character data closes
directly after a tag which cannot contain character data
closes, they co-exist on the same line.
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
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.
- For example, if you have added two sentances to a paragraph, such
+ For example, if you have added two sentences to a paragraph, such
that the line lengths on the paragraph now go over 80 columns, first
commit your change with the too-long line lengths. Then fix the line
wrapping, and commit this second change. In the commit message for
the second change, be sure to indicate that this is a whitespace-only
change, and that the translation team can ignore it.
diff --git a/en_US.ISO_8859-1/books/fdp-primer/writing-style/chapter.sgml b/en_US.ISO_8859-1/books/fdp-primer/writing-style/chapter.sgml
index 95c9cb768b..127ca29246 100644
--- a/en_US.ISO_8859-1/books/fdp-primer/writing-style/chapter.sgml
+++ b/en_US.ISO_8859-1/books/fdp-primer/writing-style/chapter.sgml
@@ -1,340 +1,340 @@
Writing style
In order to promote consistency between the myriad authors of the
FreeBSD documentation, some guidelines have been drawn up for authors to
follow.
Do not use contractions
Do not use contractions. Always spell the phrase out in full.
“Don't use contractions” would be wrong.
Avoiding contractions makes for a more formal tone, is more
precise, and slightly easier for translators.
Use the serial comma
In a list of items within a paragraph, seperate each item from
the others with a comma. Seperate the last item from the others with
a comma and the word “and”.
For example, look at the following quote;
This is a list of one, two and three items.
Is this a list of three items, “one”,
“two”, and “three”, or a list of two items,
“one” and “two and three”?
It is better to be explicit and include a serial comma;
This is a list of one, two, and three items.
Avoid redundant phrases
Try not to use redundant phrases. In particular, “the
command”, “the file”, and “man
command” are probably redundant.
These two examples show this for commands. The second example
is preferred.
Use the command cvsup to update your
sources
Use cvsup to update your sources
These two examples show this for filenames. The second example
is preferred.
… in the filename
/etc/rc.local…
… in
/etc/rc.local…
These two examples show this for manual references. The second
example is preferred (the second example uses
citerefentry).
See man csh for more
information.
See &man.csh.1;
Two spaces at the end of sentences
Always use two spaces at the end of sentences, as this
improves readability, and eases use of tools such as
emacs.
While it may be argued that a capital letter following
the end of sentence period, this is not the case, especially
in name usage. Jordan K. Hubbard
is a good
example; it has a capital H following a
period and a space, and there certainly isn't a new sentence
there.
For more information about writing style, see Elements of
Style, by William Strunk.
Style guide
To keep the source for the Handbook consistent when many different
people are editing it, please follow these style conventions.
Letter case
Tags are entered in lower case, <para>,
not <PARA>.
Text that appears in SGML contexts is generally written in upper
case, <!ENTITY…>, and
<!DOCTYPE…>, not
<!entity…> and
<!doctype…>.
Indentation
Each file starts with indentation set at column 0,
regardless of the indentation level of the file
which might contain this one.
Every start tag increases the indentation level by 2 spaces, and
every end tag decreases the indentation level by 2 spaces. Content
within elements should be indented by two spaces if the content runs
over more than one line.
For example, the source for this section looks something
like:
...
...
Indentation
Each file starts with indentation set at column 0,
regardless of the indentation level of the file
which might contain this one.
Every start tag increases the indentation level by 2 spaces, and
every end tag decreases the indentation level by 2 spaces. Content
within elements should be indented by two spaces if the content runs
over more than one line.
...
]]>
If you use Emacs or
Xemacs to edit the files then
sgml-mode should be loaded automatically, and the
Emacs local variables at the bottom of each file should enforce these
styles.
Tag style
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
at the same indent as a previous tag should not:
NIS
October 1999
...
...
...
...
...
...
...
]]>
Special tags
Some tags just don't follow the indenting rules of the
previous section; screen and
programlisting should always be
left-aligned.
…
]]>
informalexample also should be
left-aligned when it wraps a screen or
programlisting.
These examples should be separated from the rest of the
content by a blank line before and after.
Separating tags
Tags like itemizedlist which will
always have further tags inside them, and in fact don't take
character data themselves, are always on a line by
themselves.
Tags like para and
term don't need other tags to contain
normal character data, and their contents begin immediately
after the tag, on the same line.
The same applies to when these two types of tags
close.
This leads to an obvious problem when mixing these
tags.
When a starting tag which cannot contain character data
directly follows a tag of the type that requires other tags
within it to use character data, they are on separate lines.
The second tag should be properly indented.
When a tag which can contain character data closes
directly after a tag which cannot contain character data
closes, they co-exist on the same line.
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
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.
- For example, if you have added two sentances to a paragraph, such
+ For example, if you have added two sentences to a paragraph, such
that the line lengths on the paragraph now go over 80 columns, first
commit your change with the too-long line lengths. Then fix the line
wrapping, and commit this second change. In the commit message for
the second change, be sure to indicate that this is a whitespace-only
change, and that the translation team can ignore it.