Sweep through english docs and replace &ldquot; and friends with <quote>.
Approved by: nik
This commit is contained in:
parent
b2f9d5ab79
commit
4593fd98a7
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=10908
8 changed files with 103 additions and 103 deletions
en_US.ISO8859-1
articles/vm-design
books
fdp-primer
handbook
porters-handbook
|
@ -1,4 +1,4 @@
|
|||
<!-- $FreeBSD: doc/en_US.ISO8859-1/articles/vm-design/article.sgml,v 1.5 2001/07/10 13:24:13 dd Exp $ -->
|
||||
<!-- $FreeBSD: doc/en_US.ISO8859-1/articles/vm-design/article.sgml,v 1.6 2001/07/17 20:51:49 chern Exp $ -->
|
||||
<!-- FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
|
@ -29,8 +29,8 @@
|
|||
attempt to describe the whole VM enchilada, hopefully in a way that
|
||||
everyone can follow. For the last year I have concentrated on a number
|
||||
of major kernel subsystems within FreeBSD, with the VM and Swap
|
||||
subsystems being the most interesting and NFS being ‘a necessary
|
||||
chore’. I rewrote only small portions of the code. In the VM
|
||||
subsystems being the most interesting and NFS being <quote>a necessary
|
||||
chore</quote>. I rewrote only small portions of the code. In the VM
|
||||
arena the only major rewrite I have done is to the swap subsystem.
|
||||
Most of my work was cleanup and maintenance, with only moderate code
|
||||
rewriting and no major algorithmic adjustments within the VM
|
||||
|
@ -59,9 +59,9 @@
|
|||
a great deal of attention was paid to algorithm design from the
|
||||
beginning. More attention paid to the design generally leads to a clean
|
||||
and flexible codebase that can be fairly easily modified, extended, or
|
||||
replaced over time. While BSD is considered an ‘old’
|
||||
replaced over time. While BSD is considered an <quote>old</quote>
|
||||
operating system by some people, those of us who work on it tend to view
|
||||
it more as a ‘mature’ codebase which has various components
|
||||
it more as a <quote>mature</quote> codebase which has various components
|
||||
modified, extended, or replaced with modern code. It has evolved, and
|
||||
FreeBSD is at the bleeding edge no matter how old some of the code might
|
||||
be. This is an important distinction to make and one that is
|
||||
|
@ -77,8 +77,8 @@
|
|||
community—by continuous code development. The NT folk, on the
|
||||
other hand, repeatedly make the same mistakes solved by Unix decades ago
|
||||
and then spend years fixing them. Over and over again. They have a
|
||||
severe case of ‘not designed here’ and ‘we are always
|
||||
right because our marketing department says so’. I have little
|
||||
severe case of <quote>not designed here</quote> and <quote>we are always
|
||||
right because our marketing department says so</quote>. I have little
|
||||
tolerance for anyone who cannot learn from history.</para>
|
||||
|
||||
<para>Much of the apparent complexity of the FreeBSD design, especially in
|
||||
|
@ -89,8 +89,8 @@
|
|||
these issues become most apparent when system resources begin to get
|
||||
stressed. As I describe FreeBSD's VM/Swap subsystem the reader should
|
||||
always keep two points in mind. First, the most important aspect of
|
||||
performance design is what is known as “Optimizing the Critical
|
||||
Path”. It is often the case that performance optimizations add a
|
||||
performance design is what is known as <quote>Optimizing the Critical
|
||||
Path</quote>. It is often the case that performance optimizations add a
|
||||
little bloat to the code in order to make the critical path perform
|
||||
better. Second, a solid, generalized design outperforms a
|
||||
heavily-optimized design over the long run. While a generalized design
|
||||
|
@ -267,7 +267,7 @@
|
|||
no longer accessible by anyone. That page in B can be freed.</para>
|
||||
|
||||
<para>FreeBSD solves the deep layering problem with a special optimization
|
||||
called the “All Shadowed Case”. This case occurs if either
|
||||
called the <quote>All Shadowed Case</quote>. This case occurs if either
|
||||
C1 or C2 take sufficient COW faults to completely shadow all pages in B.
|
||||
Lets say that C1 achieves this. C1 can now bypass B entirely, so rather
|
||||
then have C1->B->A and C2->B->A we now have C1->A and C2->B->A. But
|
||||
|
@ -317,7 +317,7 @@
|
|||
store—even if only a few pages of that object are swap-backed.
|
||||
This creates a kernel memory fragmentation problem when large objects
|
||||
are mapped, or processes with large runsizes (RSS) fork. Also, in order
|
||||
to keep track of swap space, a ‘list of holes’ is kept in
|
||||
to keep track of swap space, a <quote>list of holes</quote> is kept in
|
||||
kernel memory, and this tends to get severely fragmented as well. Since
|
||||
the 'list of holes' is a linear list, the swap allocation and freeing
|
||||
performance is a non-optimal O(n)-per-page. It also requires kernel
|
||||
|
@ -411,7 +411,7 @@
|
|||
flushed pages are moved from the inactive queue to the cache queue. At
|
||||
this point, pages in the cache queue can still be reactivated by a VM
|
||||
fault at relatively low cost. However, pages in the cache queue are
|
||||
considered to be ‘immediately freeable’ and will be reused
|
||||
considered to be <quote>immediately freeable</quote> and will be reused
|
||||
in an LRU (least-recently used) fashion when the system needs to
|
||||
allocate new memory.</para>
|
||||
|
||||
|
@ -557,7 +557,7 @@
|
|||
<qandaset>
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>What is “the interleaving algorithm” that you
|
||||
<para>What is <quote>the interleaving algorithm</quote> that you
|
||||
refer to in your listing of the ills of the FreeBSD 3.x swap
|
||||
arrangements?</para>
|
||||
</question>
|
||||
|
@ -566,7 +566,7 @@
|
|||
<para>FreeBSD uses a fixed swap interleave which defaults to 4. This
|
||||
means that FreeBSD reserves space for four swap areas even if you
|
||||
only have one, two, or three. Since swap is interleaved the linear
|
||||
address space representing the ‘four swap areas’ will be
|
||||
address space representing the <quote>four swap areas</quote> will be
|
||||
fragmented if you don't actually have four swap areas. For
|
||||
example, if you have two swap areas A and B FreeBSD's address
|
||||
space representation for that swap area will be interleaved in
|
||||
|
@ -574,15 +574,15 @@
|
|||
|
||||
<literallayout>A B C D A B C D A B C D A B C D</literallayout>
|
||||
|
||||
<para>FreeBSD 3.x uses a ‘sequential list of free
|
||||
regions’ approach to accounting for the free swap areas.
|
||||
<para>FreeBSD 3.x uses a <quote>sequential list of free
|
||||
regions</quote> approach to accounting for the free swap areas.
|
||||
The idea is that large blocks of free linear space can be
|
||||
represented with a single list node
|
||||
(<filename>kern/subr_rlist.c</filename>). But due to the
|
||||
fragmentation the sequential list winds up being insanely
|
||||
fragmented. In the above example, completely unused swap will
|
||||
have A and B shown as ‘free’ and C and D shown as
|
||||
‘all allocated’. Each A-B sequence requires a list
|
||||
have A and B shown as <quote>free</quote> and C and D shown as
|
||||
<quote>all allocated</quote>. Each A-B sequence requires a list
|
||||
node to account for because C and D are holes, so the list node
|
||||
cannot be combined with the next A-B sequence.</para>
|
||||
|
||||
|
@ -637,7 +637,7 @@
|
|||
|
||||
<answer>
|
||||
<para>Yes, that is confusing. The relationship is
|
||||
“goal” verses “reality”. Our goal is to
|
||||
<quote>goal</quote> verses <quote>reality</quote>. Our goal is to
|
||||
separate the pages but the reality is that if we are not in a
|
||||
memory crunch, we don't really have to.</para>
|
||||
|
||||
|
@ -734,9 +734,9 @@
|
|||
|
||||
<para>In regards to the memory overhead of a page table verses the
|
||||
<literal>pv_entry</literal> scheme: Linux uses
|
||||
‘permanent’ page tables that are not throw away, but
|
||||
<quote>permanent</quote> page tables that are not throw away, but
|
||||
does not need a <literal>pv_entry</literal> for each potentially
|
||||
mapped pte. FreeBSD uses ‘throw away’ page tables but
|
||||
mapped pte. FreeBSD uses <quote>throw away</quote> page tables but
|
||||
adds in a <literal>pv_entry</literal> structure for each
|
||||
actually-mapped pte. I think memory utilization winds up being
|
||||
about the same, giving FreeBSD an algorithmic advantage with its
|
||||
|
@ -762,7 +762,7 @@
|
|||
cached data you read from offset 0!</para>
|
||||
|
||||
<para>Now, I am simplifying things greatly. What I just described
|
||||
is what is called a ‘direct mapped’ hardware memory
|
||||
is what is called a <quote>direct mapped</quote> hardware memory
|
||||
cache. Most modern caches are what are called
|
||||
2-way-set-associative or 4-way-set-associative caches. The
|
||||
set-associatively allows you to access up to N different memory
|
||||
|
@ -819,8 +819,8 @@
|
|||
be if the program had been run directly in a physical address
|
||||
space.</para>
|
||||
|
||||
<para>Note that I say ‘reasonably’ contiguous rather
|
||||
than simply ‘contiguous’. From the point of view of a
|
||||
<para>Note that I say <quote>reasonably</quote> contiguous rather
|
||||
than simply <quote>contiguous</quote>. From the point of view of a
|
||||
128K direct mapped cache, the physical address 0 is the same as
|
||||
the physical address 128K. So two side-by-side pages in your
|
||||
virtual address space may wind up being offset 128K and offset
|
||||
|
|
|
@ -27,7 +27,7 @@
|
|||
ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml,v 1.30 2001/10/02 05:24:37 murray Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml,v 1.31 2001/10/02 05:28:56 murray Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sgml-markup">
|
||||
|
@ -509,7 +509,7 @@
|
|||
|
||||
<para>If you have content that should be rendered in a fixed pitch
|
||||
(typewriter) typeface, use <sgmltag>tt</sgmltag> (for
|
||||
“teletype”).</para>
|
||||
<quote>teletype</quote>).</para>
|
||||
|
||||
<example>
|
||||
<title><sgmltag>tt</sgmltag></title>
|
||||
|
@ -691,7 +691,7 @@
|
|||
marked.</para>
|
||||
|
||||
<para>Throughout the rest of this document, the term
|
||||
“DocBook” is used to mean the FreeBSD extended DocBook
|
||||
<quote>DocBook</quote> is used to mean the FreeBSD extended DocBook
|
||||
DTD.</para>
|
||||
|
||||
<note>
|
||||
|
@ -1065,7 +1065,7 @@
|
|||
sidebars.</title>
|
||||
|
||||
<para>You may need to include extra information separate from the
|
||||
main body of the text. Typically this is “meta”
|
||||
main body of the text. Typically this is <quote>meta</quote>
|
||||
information that the user should be aware of.</para>
|
||||
|
||||
<para>Depending on the nature of the information, one of
|
||||
|
@ -1671,7 +1671,7 @@ This is the file called 'foo2'</screen>
|
|||
the options that a command might take.</para>
|
||||
|
||||
<para>Finally, you will often want to list a command with its manual
|
||||
section number, in the “command(number)” format so
|
||||
section number, in the <quote>command(number)</quote> format so
|
||||
common in Unix manuals.</para>
|
||||
|
||||
<para>Mark up application names with
|
||||
|
@ -1710,7 +1710,7 @@ This is the file called 'foo2'</screen>
|
|||
]></programlisting>
|
||||
|
||||
<para>Use <sgmltag>command</sgmltag> when you want to include a
|
||||
command name “in-line” but present it as something the
|
||||
command name <quote>in-line</quote> but present it as something the
|
||||
user should type in.</para>
|
||||
|
||||
<para>Use <sgmltag>option</sgmltag> to mark up a command's
|
||||
|
@ -2077,7 +2077,7 @@ This is the file called 'foo2'</screen>
|
|||
<sect3>
|
||||
<title>Literal text</title>
|
||||
|
||||
<para>You will often need to include “literal” text in the
|
||||
<para>You will often need to include <quote>literal</quote> 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.</para>
|
||||
|
@ -2085,7 +2085,7 @@ This is the file called 'foo2'</screen>
|
|||
<para>Some of the time, <sgmltag>programlisting</sgmltag> will be
|
||||
sufficient to denote this text. <sgmltag>programlisting</sgmltag>
|
||||
is not always appropriate, particularly when you want to include a
|
||||
portion of a file “in-line” with the rest of the
|
||||
portion of a file <quote>in-line</quote> with the rest of the
|
||||
paragraph.</para>
|
||||
|
||||
<para>On these occasions, use <sgmltag>literal</sgmltag>.</para>
|
||||
|
@ -2542,7 +2542,7 @@ IMAGES= chapter1/fig1.png
|
|||
|
||||
<note>
|
||||
<para>That last one is a bad example. Never use words like
|
||||
“this” or “here” as the source for the
|
||||
<quote>this</quote> or <quote>here</quote> 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.</para>
|
||||
</note>
|
||||
|
|
|
@ -27,7 +27,7 @@
|
|||
ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/sgml-primer/chapter.sgml,v 1.19 2001/07/17 20:51:51 chern Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/sgml-primer/chapter.sgml,v 1.20 2001/10/02 05:28:56 murray Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sgml-primer">
|
||||
|
@ -54,8 +54,8 @@
|
|||
machine-usable format, you expect machines to be able to use it and
|
||||
manipulate it intelligently. You would like to indicate that certain
|
||||
phrases should be emphasised, or added to a glossary, or be hyperlinks.
|
||||
You might want filenames to be shown in a “typewriter” style
|
||||
font for viewing on screen, but as “italics” when printed,
|
||||
You might want filenames to be shown in a <quote>typewriter</quote> style
|
||||
font for viewing on screen, but as <quote>italics</quote> when printed,
|
||||
or any of a myriad of other options for presentation.</para>
|
||||
|
||||
<para>It was once hoped that Artificial Intelligence (AI) would make this
|
||||
|
@ -79,8 +79,8 @@
|
|||
computer processing the document cannot. For this we need
|
||||
markup.</para>
|
||||
|
||||
<para>“Markup” is commonly used to describe “adding
|
||||
value” or “increasing cost”. The term takes on both
|
||||
<para><quote>Markup</quote> is commonly used to describe <quote>adding
|
||||
value</quote> or <quote>increasing cost</quote>. The term takes on both
|
||||
these meanings when applied to text. Markup is additional text included
|
||||
in the document, distinguished from the document's content in some way,
|
||||
so that programs that process the document can read the markup and use
|
||||
|
@ -172,14 +172,14 @@
|
|||
processing.</para>
|
||||
|
||||
<para>For example, consider a typical book. At the very top level, the
|
||||
book is itself an element. This “book” element obviously
|
||||
book is itself an element. This <quote>book</quote> element obviously
|
||||
contains chapters, which can be considered to be elements in their own
|
||||
right. Each chapter will contain more elements, such as paragraphs,
|
||||
quotations, and footnotes. Each paragraph might contain further
|
||||
elements, identifying content that was direct speech, or the name of a
|
||||
character in the story.</para>
|
||||
|
||||
<para>You might like to think of this as “chunking” content.
|
||||
<para>You might like to think of this as <quote>chunking</quote> content.
|
||||
At the very top level you have one chunk, the book. Look a little
|
||||
deeper, and you have more chunks, the individual chapters. These are
|
||||
chunked further into paragraphs, footnotes, character names, and so
|
||||
|
@ -266,10 +266,10 @@
|
|||
end.</para>
|
||||
|
||||
<para>When this document (or anyone else knowledgable about SGML) refers
|
||||
to “the <p> tag” they mean the literal text
|
||||
to <quote>the <p> tag</quote> they mean the literal text
|
||||
consisting of the three characters <literal><</literal>,
|
||||
<literal>p</literal>, and <literal>></literal>. But the phrase
|
||||
“the <p> element” refers to the whole
|
||||
<quote>the <p> element</quote> refers to the whole
|
||||
element.</para>
|
||||
|
||||
<para>This distinction <emphasis>is</emphasis> very subtle. But keep it
|
||||
|
@ -609,7 +609,7 @@ nsgmls:example.sgml:6:8:E: end tag for "HEAD" which is not finished</screen>
|
|||
<listitem>
|
||||
<para>This indicates the owner of the FPI.</para>
|
||||
|
||||
<para>If this string starts with “ISO” then this is an
|
||||
<para>If this string starts with <quote>ISO</quote> then this is an
|
||||
ISO owned FPI. For example, the FPI <literal>"ISO
|
||||
8879:1986//ENTITIES Greek Symbols//EN"</literal> lists
|
||||
<literal>ISO 8879:1986</literal> as being the owner for the set
|
||||
|
@ -795,7 +795,7 @@ nsgmls:example.sgml:6:8:E: end tag for "HEAD" which is not finished</screen>
|
|||
shows, it is possible to use SGML syntax within your document.</para>
|
||||
|
||||
<para>The delimiter for SGML comments is the string
|
||||
“<literal>--</literal>”. The first occurence of this string
|
||||
<quote><literal>--</literal></quote>. The first occurence of this string
|
||||
opens a comment, and the second closes it.</para>
|
||||
|
||||
<example>
|
||||
|
@ -1306,7 +1306,7 @@ nsgmls:example.sgml:6:8:E: end tag for "HEAD" which is not finished</screen>
|
|||
|
||||
<para>SGML provides a mechanism to indicate that particular pieces of the
|
||||
document should be processed in a special way. These are termed
|
||||
“marked sections”.</para>
|
||||
<quote>marked sections</quote>.</para>
|
||||
|
||||
<example>
|
||||
<title>Structure of a marked section</title>
|
||||
|
@ -1343,7 +1343,7 @@ nsgmls:example.sgml:6:8:E: end tag for "HEAD" which is not finished</screen>
|
|||
default.</para>
|
||||
|
||||
<para>When an SGML parser is processing a document it keeps track
|
||||
of what is called the “content model”.</para>
|
||||
of what is called the <quote>content model</quote>.</para>
|
||||
|
||||
<para>Briefly, the content model describes what sort of content the
|
||||
parser is expecting to see, and what it will do with it when it
|
||||
|
@ -1352,14 +1352,14 @@ nsgmls:example.sgml:6:8:E: end tag for "HEAD" which is not finished</screen>
|
|||
<para>The two content models you will probably find most useful are
|
||||
<literal>CDATA</literal> and <literal>RCDATA</literal>.</para>
|
||||
|
||||
<para><literal>CDATA</literal> is for “Character Data”.
|
||||
<para><literal>CDATA</literal> is for <quote>Character Data</quote>.
|
||||
If the parser is in this content model then it is expecting to see
|
||||
characters, and characters only. In this model the < and &
|
||||
symbols lose their special status, and will be treated as ordinary
|
||||
characters.</para>
|
||||
|
||||
<para><literal>RCDATA</literal> is for “Entity references and
|
||||
character data” If the parser is in this content model then it
|
||||
<para><literal>RCDATA</literal> is for <quote>Entity references and
|
||||
character data</quote> If the parser is in this content model then it
|
||||
is expecting to see characters <emphasis>and</emphasis> entities.
|
||||
< loses its special status, but & will still be treated as
|
||||
starting the beginning of a general entity.</para>
|
||||
|
|
|
@ -27,7 +27,7 @@
|
|||
ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/translations/chapter.sgml,v 1.9 2001/06/13 11:36:27 tom Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/translations/chapter.sgml,v 1.10 2001/06/28 14:47:22 nik Exp $
|
||||
-->
|
||||
|
||||
<chapter id="translations">
|
||||
|
@ -71,10 +71,10 @@
|
|||
means <phrase>localisation</phrase>. They are just a convenient
|
||||
shorthand.</para>
|
||||
|
||||
<para><phrase>i18n</phrase> can be read as “i” followed by
|
||||
18 letters, followed by “n”. Similarly,
|
||||
<phrase>l10n</phrase> is “l” followed by 10 letters,
|
||||
followed by “n”.</para>
|
||||
<para><phrase>i18n</phrase> can be read as <quote>i</quote> followed by
|
||||
18 letters, followed by <quote>n</quote>. Similarly,
|
||||
<phrase>l10n</phrase> is <quote>l</quote> followed by 10 letters,
|
||||
followed by <quote>n</quote>.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
@ -191,9 +191,9 @@
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>Congratulations, you have just started the “FreeBSD
|
||||
<para>Congratulations, you have just started the <quote>FreeBSD
|
||||
<replaceable>your-language-here</replaceable> Documentation
|
||||
Translation Project”. Welcome aboard.</para>
|
||||
Translation Project</quote>. Welcome aboard.</para>
|
||||
|
||||
<para>First, decide whether or not you've got the time to spare. Since
|
||||
you are the only person working on your language at the moment it is
|
||||
|
@ -385,19 +385,19 @@
|
|||
<seglistitem>
|
||||
<seg>&eacute;</seg>
|
||||
<seg>é</seg>
|
||||
<seg>Small “e” with an acute accent</seg>
|
||||
<seg>Small <quote>e</quote> with an acute accent</seg>
|
||||
</seglistitem>
|
||||
|
||||
<seglistitem>
|
||||
<seg>&Eacute;</seg>
|
||||
<seg>É</seg>
|
||||
<seg>Large “E” with an acute accent</seg>
|
||||
<seg>Large <quote>E</quote> with an acute accent</seg>
|
||||
</seglistitem>
|
||||
|
||||
<seglistitem>
|
||||
<seg>&uuml;</seg>
|
||||
<seg>ü</seg>
|
||||
<seg>Small “u” with an umlaut</seg>
|
||||
<seg>Small <quote>u</quote> with an umlaut</seg>
|
||||
</seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
|
@ -414,7 +414,7 @@
|
|||
|
||||
<answer>
|
||||
<para>In the English documents, the reader is addressed as
|
||||
“you”, there is no formal/informal distinction as there
|
||||
<quote>you</quote>, there is no formal/informal distinction as there
|
||||
is in some languages.</para>
|
||||
|
||||
<para>If you are translating to a language which does distinguish, use
|
||||
|
|
|
@ -27,7 +27,7 @@
|
|||
ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml,v 1.19 2001/08/11 21:42:06 jim Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml,v 1.20 2001/08/11 21:45:32 jim Exp $
|
||||
-->
|
||||
|
||||
<chapter id="writing-style">
|
||||
|
@ -43,7 +43,7 @@
|
|||
|
||||
<listitem>
|
||||
<para>Do not use contractions. Always spell the phrase out in full.
|
||||
“Don't use contractions” would be wrong.</para>
|
||||
<quote>Don't use contractions</quote> would be wrong.</para>
|
||||
|
||||
<para>Avoiding contractions makes for a more formal tone, is more
|
||||
precise, and is slightly easier for translators.</para>
|
||||
|
@ -56,7 +56,7 @@
|
|||
<listitem>
|
||||
<para>In a list of items within a paragraph, separate each item from
|
||||
the others with a comma. Seperate the last item from the others with
|
||||
a comma and the word “and”.</para>
|
||||
a comma and the word <quote>and</quote>.</para>
|
||||
|
||||
<para>For example, look at the following:</para>
|
||||
|
||||
|
@ -64,9 +64,9 @@
|
|||
<para>This is a list of one, two and three items.</para>
|
||||
</blockquote>
|
||||
|
||||
<para>Is this a list of three items, “one”,
|
||||
“two”, and “three”, or a list of two items,
|
||||
“one” and “two and three”?</para>
|
||||
<para>Is this a list of three items, <quote>one</quote>,
|
||||
<quote>two</quote>, and <quote>three</quote>, or a list of two items,
|
||||
<quote>one</quote> and <quote>two and three</quote>?</para>
|
||||
|
||||
<para>It is better to be explicit and include a serial comma:</para>
|
||||
|
||||
|
@ -80,9 +80,9 @@
|
|||
<term>Avoid redundant phrases</term>
|
||||
|
||||
<listitem>
|
||||
<para>Try not to use redundant phrases. In particular, “the
|
||||
command”, “the file”, and “man
|
||||
command” are probably redundant.</para>
|
||||
<para>Try not to use redundant phrases. In particular, <quote>the
|
||||
command</quote>, <quote>the file</quote>, and <quote>man
|
||||
command</quote> are probably redundant.</para>
|
||||
|
||||
<para>These two examples show this for commands. The second example
|
||||
is preferred.</para>
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.99 2001/10/02 12:50:00 tom Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.100 2001/10/08 20:30:45 chern Exp $
|
||||
-->
|
||||
|
||||
<chapter id="advanced-networking">
|
||||
|
@ -1764,7 +1764,7 @@ ISDN BRI line</literallayout>
|
|||
<row>
|
||||
<entry>ypbind</entry>
|
||||
|
||||
<entry>“binds” an NIS client to its NIS
|
||||
<entry><quote>binds</quote> an NIS client to its NIS
|
||||
server. It will take the NIS domainname from the
|
||||
system, and using RPC, connect to the
|
||||
server. <command>ypbind</command> is the core of
|
||||
|
@ -2876,7 +2876,7 @@ TWO (,hotel,test-domain)
|
|||
maps</emphasis>. If you forget to do this, the new user will
|
||||
not be able to login anywhere except on the NIS master.
|
||||
For example, if we needed to add a new user
|
||||
“jsmith” to the lab, we would:</para>
|
||||
<quote>jsmith</quote> to the lab, we would:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
|
||||
&prompt.root; <userinput>cd /var/yp</userinput>
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml,v 1.161 2001/09/26 16:42:02 jdp Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml,v 1.162 2001/10/09 23:53:00 chern Exp $
|
||||
-->
|
||||
|
||||
<appendix id="mirrors">
|
||||
|
@ -1222,7 +1222,7 @@
|
|||
|
||||
<para><application>CTM</application> will give you a local copy of
|
||||
the FreeBSD source trees. There are a number of
|
||||
“flavors” of the tree available. Whether you wish
|
||||
<quote>flavors</quote> of the tree available. Whether you wish
|
||||
to track the entire CVS tree or just one of the branches,
|
||||
<application>CTM</application> can provide you the information.
|
||||
If you are an active developer on FreeBSD, but have lousy or
|
||||
|
@ -1239,7 +1239,7 @@
|
|||
<para>You will also need to make yourself aware of the various
|
||||
caveats related to working directly from the development sources
|
||||
rather than a pre-packaged release. This is particularly true
|
||||
if you choose the “current” sources. It is
|
||||
if you choose the <quote>current</quote> sources. It is
|
||||
recommended that you read <link linkend="current">Staying
|
||||
current with FreeBSD</link>.</para>
|
||||
</sect2>
|
||||
|
@ -1250,7 +1250,7 @@
|
|||
|
||||
<para>You will need two things: The <application>CTM</application>
|
||||
program, and the initial deltas to feed it (to get up to
|
||||
“current” levels).</para>
|
||||
<quote>current</quote> levels).</para>
|
||||
|
||||
<para>The <application>CTM</application> program has been part of
|
||||
FreeBSD ever since version 2.0 was released, and lives in
|
||||
|
@ -1264,7 +1264,7 @@
|
|||
<para><ulink
|
||||
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/">ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/</ulink></para>
|
||||
|
||||
<para>The “deltas” you feed
|
||||
<para>The <quote>deltas</quote> you feed
|
||||
<application>CTM</application> can be had two ways, FTP or
|
||||
email. If you have general FTP access to the Internet then the
|
||||
following FTP sites support access to
|
||||
|
@ -1283,9 +1283,9 @@
|
|||
|
||||
<para>Send email to &a.majordomo; to subscribe to one of the
|
||||
<application>CTM</application> distribution lists.
|
||||
“ctm-cvs-cur” supports the entire CVS tree.
|
||||
“ctm-src-cur” supports the head of the development
|
||||
branch. “ctm-src-2_2” supports the 2.2 release
|
||||
<quote>ctm-cvs-cur</quote> supports the entire CVS tree.
|
||||
<quote>ctm-src-cur</quote> supports the head of the development
|
||||
branch. <quote>ctm-src-2_2</quote> supports the 2.2 release
|
||||
branch, etc.. (If you do not know how to subscribe yourself
|
||||
using majordomo, send a message first containing the word
|
||||
<literal>help</literal> — it will send you back usage
|
||||
|
@ -1322,10 +1322,10 @@
|
|||
produced subsequently to it.</para>
|
||||
|
||||
<para>First you should determine what you already have. Everyone
|
||||
can start from an “empty” directory. You must use
|
||||
an initial “Empty” delta to start off your
|
||||
can start from an <quote>empty</quote> directory. You must use
|
||||
an initial <quote>Empty</quote> delta to start off your
|
||||
<application>CTM</application> supported tree. At some point it
|
||||
is intended that one of these “started” deltas be
|
||||
is intended that one of these <quote>started</quote> deltas be
|
||||
distributed on the CD for your convenience, however, this does
|
||||
not currently happen.</para>
|
||||
|
||||
|
@ -1334,11 +1334,11 @@
|
|||
-RELEASE CD, you can copy or extract an initial source from it.
|
||||
This will save a significant transfer of data.</para>
|
||||
|
||||
<para>You can recognize these “starter” deltas by the
|
||||
<para>You can recognize these <quote>starter</quote> deltas by the
|
||||
<literal>X</literal> appended to the number
|
||||
(<filename>src-cur.3210XEmpty.gz</filename> for instance). The
|
||||
designation following the <filename>X</filename> corresponds to
|
||||
the origin of your initial “seed”.
|
||||
the origin of your initial <quote>seed</quote>.
|
||||
<filename>Empty</filename> is an empty directory. As a rule a
|
||||
base transition from <filename>Empty</filename> is produced
|
||||
every 100 deltas. By the way, they are large! 25 to 30
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/porters-handbook/book.sgml,v 1.171 2001/10/09 16:12:09 mike Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/porters-handbook/book.sgml,v 1.172 2001/10/10 02:47:43 ache Exp $
|
||||
-->
|
||||
|
||||
<!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
|
@ -180,7 +180,7 @@ asami@cs.berkeley.edu</programlisting>
|
|||
<title><filename>pkg-plist</filename></title>
|
||||
|
||||
<para>This file lists all the files installed by the port. It is
|
||||
also called the “packing list” because the package is
|
||||
also called the <quote>packing list</quote> because the package is
|
||||
generated by packing the files listed here. The pathnames are
|
||||
relative to the installation prefix (usually
|
||||
<filename>/usr/local</filename> or
|
||||
|
@ -351,7 +351,7 @@ lib/X11/oneko/mouse.xpm
|
|||
|
||||
<para>We will look at your port, get back to you if necessary, and put
|
||||
it in the tree. Your name will also appear in the list of
|
||||
“Additional FreeBSD contributors” in the FreeBSD
|
||||
<quote>Additional FreeBSD contributors</quote> in the FreeBSD
|
||||
Handbook and other files. Isn't that great?!? <!-- smiley
|
||||
-->:-)</para>
|
||||
|
||||
|
@ -359,10 +359,10 @@ lib/X11/oneko/mouse.xpm
|
|||
<para>You can make our work a lot easier, if you use a good
|
||||
description in the synopsis of the problem report.
|
||||
We prefer something like
|
||||
“New port: <short description of the port>” for
|
||||
<quote>New port: <short description of the port></quote> for
|
||||
new ports and
|
||||
“Update port: <category>/<port> <short description
|
||||
of the update>” for port updates.
|
||||
<quote>Update port: <category>/<port> <short description
|
||||
of the update></quote> for port updates.
|
||||
If you stick to this scheme, the chance that one takes a look at
|
||||
your PR soon is much bigger.</para>
|
||||
</note>
|
||||
|
@ -490,7 +490,7 @@ lib/X11/oneko/mouse.xpm
|
|||
target in your <filename>Makefile</filename>.</para>
|
||||
|
||||
<note>
|
||||
<para>The “main” targets (e.g.,
|
||||
<para>The <quote>main</quote> targets (e.g.,
|
||||
<maketarget>extract</maketarget>,
|
||||
<maketarget>configure</maketarget>, etc.) do nothing more than
|
||||
make sure all the stages up to that one are completed and call
|
||||
|
@ -523,7 +523,7 @@ lib/X11/oneko/mouse.xpm
|
|||
|
||||
<para>If you cannot find somewhere convenient and reliable to put the
|
||||
distfile
|
||||
we can “house” it ourselves
|
||||
we can <quote>house</quote> it ourselves
|
||||
on <hostid>ftp.FreeBSD.org</hostid>.
|
||||
The distfile must be placed into
|
||||
<filename>~/public_distfiles/</filename> of someone's
|
||||
|
@ -566,7 +566,7 @@ lib/X11/oneko/mouse.xpm
|
|||
to compile or install, you should take a look at one of Larry Wall's
|
||||
classic <application>Configure</application> scripts and perhaps do
|
||||
something similar yourself. The goal of the new ports collection is
|
||||
to make each port as “plug-and-play” as possible for the
|
||||
to make each port as <quote>plug-and-play</quote> as possible for the
|
||||
end-user while using a minimum of disk space.</para>
|
||||
|
||||
<note>
|
||||
|
@ -618,7 +618,7 @@ lib/X11/oneko/mouse.xpm
|
|||
|
||||
<para>If your port requires user input to build, configure, or install,
|
||||
then set <makevar>IS_INTERACTIVE</makevar> in your Makefile. This
|
||||
will allow “overnight builds” to skip your port if the
|
||||
will allow <quote>overnight builds</quote> to skip your port if the
|
||||
user sets the variable <envar>BATCH</envar> in his environment (and
|
||||
if the user sets the variable <envar>INTERACTIVE</envar>, then
|
||||
<emphasis>only</emphasis> those ports requiring interaction are
|
||||
|
@ -1169,7 +1169,7 @@ MASTER_SITE_SUBDIR= applications</programlisting>
|
|||
ports tree to build and install it if it is not found.</para>
|
||||
|
||||
<note>
|
||||
<para>“build” here means everything from extraction to
|
||||
<para><quote>build</quote> here means everything from extraction to
|
||||
compilation. The dependency is checked from within the
|
||||
<maketarget>extract</maketarget> target. The
|
||||
<replaceable>target</replaceable> part can be omitted if it is
|
||||
|
@ -2117,7 +2117,7 @@ diff -u -r1.15 pkg-plist
|
|||
<title><filename>pkg-req</filename></title>
|
||||
|
||||
<para>If your port needs to determine if it should install or not, you
|
||||
can create a <filename>pkg-req</filename> “requirements”
|
||||
can create a <filename>pkg-req</filename> <quote>requirements</quote>
|
||||
script. It will be invoked automatically at
|
||||
installation/deinstallation time to determine whether or not
|
||||
installation/deinstallation should proceed.</para>
|
||||
|
@ -2276,7 +2276,7 @@ PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}</programlisting>
|
|||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>If the port has a “do not sell for profit” type of
|
||||
<para>If the port has a <quote>do not sell for profit</quote> type of
|
||||
license, set the variable <makevar>NO_CDROM</makevar> to a string
|
||||
describing the reason why. We will make sure such ports will not go
|
||||
into the CDROM come release time. The distfile and package will
|
||||
|
@ -2294,7 +2294,7 @@ PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}</programlisting>
|
|||
|
||||
<listitem>
|
||||
<para>If the port has legal restrictions on who can use it (e.g.,
|
||||
patented stuff) or has a “no commercial use” license,
|
||||
patented stuff) or has a <quote>no commercial use</quote> license,
|
||||
set the variable <makevar>RESTRICTED</makevar> to be the string
|
||||
describing the reason why. For such ports, the distfiles/packages
|
||||
will not be available even from our FTP sites.</para>
|
||||
|
@ -3124,7 +3124,7 @@ PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}</programlisting>
|
|||
|
||||
<note>
|
||||
<para>Note that 2.2-STABLE sometimes identifies itself as
|
||||
“2.2.5-STABLE” after the 2.2.5-RELEASE. The pattern
|
||||
<quote>2.2.5-STABLE</quote> after the 2.2.5-RELEASE. The pattern
|
||||
used to be year followed by the month, but we decided to change it
|
||||
to a more straightforward major/minor system starting from 2.2.
|
||||
This is because the parallel development on several branches made
|
||||
|
@ -3211,13 +3211,13 @@ PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}</programlisting>
|
|||
|
||||
<row>
|
||||
<entry><makevar>LOCALBASE</makevar></entry>
|
||||
<entry>The base of the “local” tree (e.g.,
|
||||
<entry>The base of the <quote>local</quote> tree (e.g.,
|
||||
<literal>/usr/local/</literal>)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><makevar>X11BASE</makevar></entry>
|
||||
<entry>The base of the “X11” tree (e.g.,
|
||||
<entry>The base of the <quote>X11</quote> tree (e.g.,
|
||||
<literal>/usr/X11R6</literal>)</entry>
|
||||
</row>
|
||||
|
||||
|
@ -3466,7 +3466,7 @@ post-install:
|
|||
the rules governing
|
||||
<filename>/usr</filename> pretty much apply to
|
||||
<filename>/usr/local</filename> too. The exception are ports
|
||||
dealing with USENET “news”. They may use
|
||||
dealing with USENET <quote>news</quote>. They may use
|
||||
<filename><makevar>PREFIX</makevar>/news</filename> as a destination
|
||||
for their files.</para>
|
||||
</sect1>
|
||||
|
|
Loading…
Reference in a new issue