diff --git a/zh_TW.Big5/books/fdp-primer/writing-style/chapter.sgml b/zh_TW.Big5/books/fdp-primer/writing-style/chapter.sgml
index bf11159bf9..dbabe8f1c3 100644
--- a/zh_TW.Big5/books/fdp-primer/writing-style/chapter.sgml
+++ b/zh_TW.Big5/books/fdp-primer/writing-style/chapter.sgml
@@ -1,489 +1,470 @@
文件的撰寫風格
- In order to promote consistency between the myriad authors of the
- FreeBSD documentation, some guidelines have been drawn up for authors to
- follow.
+ 由於 FreeBSD 文件是由眾多作者所維護的，為了保持寫作風格的一貫性，
+ 於是就產生較有共識的寫作規則，請各位記得要遵守。
- Use American English spelling
+ 使用美式英語
- There are several variants of English, with different spellings
- for the same word. Where spellings differ, use the American English
- variant. color
, not colour
,
- rationalize
, not rationalise
, and so
- on.
+ 同一個字在不同種類的英語會有著不同的拼法。
+ 遇到拼字不同的情況，請採用美式英語拼法。 像是：
+ 請改用 color
，而非 colour
。
+ 請改用 rationalize
，而非 rationalise
+ 等等類似字彙。
- The use of British English may be accepted in the case
- of a contributed article, however the spelling must be
- consistent within the whole document. The other documents
- such as books, web site, manual pages, etc. will have to use
- American English.
+ 若文章採用英式英語也可以接受，但必須全篇文章都採用同一拼法才行
+ 。 而文件的其他部份，像是書、網頁、 manual
+ 說明等則必須採用美式英語。
- Do not use contractions
+ 不要用簡寫
- Do not use contractions. Always spell the phrase out in full.
- Don't use contractions
would be wrong.
+ 請不要簡寫(contraction)。 請務必將完整的字寫出來。 比如：
+ Don't use contractions
這句有用到簡寫，就要避免。
- Avoiding contractions makes for a more formal tone, is more
- precise, and is slightly easier for translators.
+ 正式書面寫法避免簡寫的原因，乃是因為如此一來字句意思較精準，
+ 且對譯者會比較輕鬆些。
- Use the serial comma
+ 正確使用 serial comma 以及頓號
- In a list of items within a paragraph, separate each item from
- the others with a comma. Separate the last item from the others with
- a comma and the word and
.
+ 英文段落通常會逗號(,)作為該句所提到的各項目的語氣區隔。
+ 並且會在最後一個提到的項目時，先加上逗號再接上 and
，
+ 最後才是最後的項目。
- For example, look at the following:
+ 舉個例子，看看下面這句：
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
?
+ 那麼這一句到底是有三個項目(one
、two
+ 、three
)呢？或者是只有兩個項目(one
、
+ two and three
)呢？
- It is better to be explicit and include a serial comma:
+ 因此較妥的方式是以 serial comma 的方式，才能正確表達語意：
This is a list of one, two, and three items.
+
+ 然而，在翻譯過程中，建議把逗號(,)部份改為頓號(、)，並且
+ and
的部份可略而不翻，以免語意頓塞。
- Avoid redundant phrases
+ 避免使用贅詞
- Try not to use redundant phrases. In particular, the
- command
, the file
, and man
- command
are probably redundant.
+ 請試著避免使用贅詞(redundant phrase)。 尤其是
+ 這個指令
、這個檔案
、man
+ 指令
這幾個通常都是不必要的贅詞。
- These two examples show this for commands. The second example
- is preferred.
+ 以指令(command)方面舉例，比較妥當的用法是第二句的例子：
- Use the command cvsup to update your
- sources.
+ 使用 cvsup 指令來更新原始碼。
- Use cvsup to update your sources.
+ 使用 cvsup 來更新原始碼。
- These two examples show this for filenames. The second example
- is preferred.
+ 以檔案(filename)方面舉例，比較妥當的用法是第二句的例子：
- … in the filename
- /etc/rc.local…
+ … 在這個
+ /etc/rc.local 檔案 …
- … in
- /etc/rc.local…
+ … 在
+ /etc/rc.local 檔 …
- These two examples show this for manual references. The second
- example is preferred (the second example uses
- citerefentry).
+ 以 man(manual)方面舉例，比較妥當的用法是第二句(有用到 SGML
+ citerefentry tag)：
- See man csh for more
- information.
+ 請打 man csh 指令以參閱詳情說明。
- See &man.csh.1;.
+ 詳情請參閱 &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
- a period denotes a new sentence, 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 is not a new sentence
- there.
+ 為增進文章之易讀，以及讓 Emacs
+ 之類的工具容易運用，請在每一完整句子後面加上兩個空白。
+
+ 不過，句號(.)後面有接大寫字母，
+ 並不一定表示前一個句點所在處就是完整句子，
+ 尤其是名字部份常常會有這現象。 像是 Jordan K. Hubbard
+ 這人名就是很好的例證：句號後面接空白，然後是大寫的
+ H，然而這肯定並不是兩段句子。
- For more information about writing style, see Elements of
- Style, by William Strunk.
+ 撰寫風格的相關細節，可參閱 William Strunk 所寫的 Elements of Style。
Style guide
- To keep the source for the Handbook consistent when many different
- people are editing it, please follow these style conventions.
+ 由於 Handbook 是由眾多作者所維護，為了保持寫作風格的一貫性，
+ 請遵守下列撰寫風格。
- Letter case
+ 大小寫
- Tags are entered in lower case, <para>,
- not <PARA>.
+ Tag 的部份都是用小寫字母，譬如是用 <para>
+ ，而非 <PARA>。
- Text that appears in SGML contexts is generally written in upper
- case, <!ENTITY…>, and
- <!DOCTYPE…>, not
- <!entity…> and
- <!doctype…>.
+ 而 SGML 內文則是用大寫字母表示，像是：
+ <!ENTITY…> 及
+ <!DOCTYPE…>，
+ 而不是
+ <!entity…> 及
+ <!doctype…>。
- Acronyms
-
- Acronyms should generally be spelled out the first time
- they appear in a book, 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
- 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
- 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.
+ 縮寫字
+
+ 縮寫字(acronym)通常在書中第一次提到時，必須同時列出完整拼法，
+ 比如："Network Time Protocol (NTP)"。
+ 定義縮寫字之後，應該儘量只使用該縮寫字(而非完整詞彙，
+ 除非使用完整詞彙可以更能表達語意)來表達即可。
+ 通常每本書只會第一次提到時，才會列出完整詞彙，
+ 但若您高興也可以在每章第一次提到時又列出完整詞彙。
+
+ 此外，同一縮寫字在前三次使用時，須使用 <acronym> tag，
+ 並把完整詞彙附在 role 屬性內做說明。
+ 如此一來就會建立詞彙表，並且當滑鼠移至該縮寫字上方時，
+ 就會顯示完整詞彙。
- Indentation
+ 縮排
- Each file starts with indentation set at column 0,
- regardless of the indentation level of the file
- which might contain this one.
+ 無論 檔案縮排設定為何，
+ 每個檔案一開始的縮排(indentation)都是從 column 0 開始
- Opening tags increase the indentation level by 2 spaces.
- Closing tags decrease the indentation level by 2 spaces. Blocks
- of 8 spaces at the start of a line should be replaced with a tab.
- Do not use
- spaces in front of tabs, and do not add extraneous whitespace at the
- end of a line. Content
- within elements should be indented by two spaces if the content runs
- over more than one line.
+ 未完的 tag 會以多兩個空白來增加縮排，
+ 結尾的 tag 則少兩個空白來縮減縮排。 若已達 8 個空白，則以 tab 取代之。
+ 此外，在 tab 前面不要再用空白，也不要在每行後面加上空白。
+ 每個 tag 的內文若超過一行的話，則接下來的就多兩個空白以做縮排。
- 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.
+ 無論 檔案縮排設定為何，
+ 每個檔案一開始的縮排(indentation)都是從 column 0 開始。
...
]]>
- 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.
+ 若用 Emacs 或
+ XEmacs 來編輯這檔，那麼會自動進入
+ sgml-mode 模式，
+ 然後就會強制使用每個檔案最下方的環境設定。
- Vim users might want to configure
- their editor with:
+ Vim 愛用者也可以用下列設定來調整：
augroup sgmledit
- autocmd FileType sgml set formatoptions=cq2l " Special formatting options
- autocmd FileType sgml set textwidth=70 " Wrap lines at 70 columns
- autocmd FileType sgml set shiftwidth=2 " Automatically indent
- autocmd FileType sgml set softtabstop=2 " Tab key indents 2 spaces
- autocmd FileType sgml set tabstop=8 " Replace 8 spaces with a tab
- autocmd FileType sgml set autoindent " Automatic indentation
+ autocmd FileType sgml set formatoptions=cq2l " 特殊格式選項
+ autocmd FileType sgml set textwidth=70 " 在 70 column 處即自動換行
+ autocmd FileType sgml set shiftwidth=2 " 自動縮排 2 個空白
+ autocmd FileType sgml set softtabstop=2 " 按 Tab 會自動轉為兩個空白縮排
+ autocmd FileType sgml set tabstop=8 " 把 8 個空白轉為 tab
+ autocmd FileType sgml set autoindent " 自動縮排
augroup END
- Tag style
+ Tag 風格
- Tag spacing
+ Tag 空行
- 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:
+ 同一縮排等級的 tag 要以空一行來做區隔，而不同縮排等級的則不必。
+ 比如：
NIS
October 1999
...
...
...
...
...
...
...
]]>
Separating tags
Tags like itemizedlist which will
always have further tags inside them, and in fact do not take
character data themselves, are always on a line by
themselves.
Tags like para and
term do not 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 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.
Nonbreaking space
Avoid line breaks in places where they look ugly
or make it difficult to follow a sentence. Line breaks depend
on the width of the chosen output medium. In particular, viewing
the HTML documentation with a text browser can lead to badly
formatted paragraphs like the next one:
Data capacity ranges from 40 MB to 15
GB. Hardware compression …
The general entity prohibits
line breaks between parts belonging together. Use nonbreaking
spaces in the following places:
between numbers and units:
between program names and version numbers:
between multiword names (use with caution when applying this
to more than 3-4 word names like The FreeBSD Brazilian
Portuguese Documentation Project
):
Word list
The following is a small list of words spelled the way they
should be used in the FreeBSD Documentation Project. If the
word you are looking for is not in this list, then please
consult the O'Reilly
word list.
2.2.X
4.X-STABLE
CD-ROM
DoS (Denial of Service)
Ports Collection
IPsec
Internet
MHz
Soft Updates
Unix
disk label
email
file system
manual page
mail server
name server
null-modem
web server