diff --git a/documentation/content/en/books/fdp-primer/trademarks/_index.adoc b/documentation/content/en/books/fdp-primer/trademarks/_index.adoc index c0a457e114..a57a2755c8 100644 --- a/documentation/content/en/books/fdp-primer/trademarks/_index.adoc +++ b/documentation/content/en/books/fdp-primer/trademarks/_index.adoc @@ -1,96 +1,97 @@ --- title: Chapter 13. Trademarks prev: books/fdp-primer/editor-config/ next: books/fdp-primer/see-also description: Guidelines for trademarks in the FreeBSD Documentation Project tags: ["trademarks", "AsciiDoctor", "HTML"] showBookMenu: true weight: 14 path: "/books/fdp-primer/" --- [[trademarks]] = Trademarks :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 13 :partnums: :source-highlighter: rouge :experimental: :images-path: books/fdp-primer/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] -For all documents on the FreeBSD Documentation Project, it is necessary to cite registered trademarks, and that is a duty of every writer and contributor. +For all documents on the FreeBSD Documentation Project, citing registered trademarks is necessary and other trademarks is customary, and that is a requirement for every writer and contributor. [[trademark-symbols]] == Trademark Symbols -Add a registered trademark symbol (TM), (R), or other symbols in the first occurrence of the company or software name, and always when using logos. -Also, write the company or software name following its trademark guidelines. +Append a trademark symbol ((TM), (R), or other) to the first occurrence of the trademarked name, and always when using logos. +Use the extref:{fdp-primer}/writing-style/#writing-style-special-characters[equivalent ASCII sequence], which will be rendered as the actual Unicode character. +Also, write the trademarked name following its trademark guidelines. -When in doubt, research the company on the Internet or the software's website in addition to the link:https://www.uspto.gov/trademarks[United States Patent and Trademark Office site]. +When in doubt, research the trademark owner's website, the product's website, and or the link:https://www.uspto.gov/trademarks[United States Patent and Trademark Office trademark search website]. [[trademark-citing]] == Trademark Citing -It is customary to cite trademarks in technical documentation, and the FreeBSD Documentation Project provides a template for it, which also avoids duplicating trademarks in the documents. +The FreeBSD Documentation Project provides a template for citing trademarks, which also avoids duplicating trademarks in the documents. -First, check the project's link:https://cgit.freebsd.org/doc/tree/documentation/themes/beastie/i18n/en.toml#n197[template] for the trademark and then add it to the trademarks tag on the `Front Matter` section of the document, placed at the beginning of each document. +First, look for the trademark in the link:https://cgit.freebsd.org/doc/tree/documentation/themes/beastie/i18n/en.toml#n328[Copyright section in the project's template], then add it to the trademarks tag on the `Front Matter` section of the document, located at the beginning of each document. The following is an example of the `Front Matter` of the extref:{contributing}[Contributing to FreeBSD] article: .... --- title: Contributing to FreeBSD authors: - author: Jordan Hubbard - author: Sam Lawrance - author: Mark Linimon description: How to contribute to the FreeBSD Project trademarks: ["freebsd", "ieee", "general"] weight: 15 tags: ["Contributing", "FreeBSD", "Non-Programmer Tasks", "Programmer Tasks"] --- .... The trademark tags `freebsd`, `ieee`, and `general` will be automatically rendered when building the document like this: .... FreeBSD is a registered trademark of the FreeBSD Foundation. IEEE, POSIX, and 802 are registered trademarks of Institute of Electrical and Electronics Engineers, Inc. in the United States. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the “®” symbol. .... If a trademark is not present in the project's template, it must be submitted. Any developer or contributor can update the trademarks. The `freebsd` and `general` trademark tags are usually present in all documents. diff --git a/documentation/content/en/books/fdp-primer/writing-style/_index.adoc b/documentation/content/en/books/fdp-primer/writing-style/_index.adoc index ba17cdf890..1fe5811de1 100644 --- a/documentation/content/en/books/fdp-primer/writing-style/_index.adoc +++ b/documentation/content/en/books/fdp-primer/writing-style/_index.adoc @@ -1,254 +1,254 @@ --- title: Chapter 11. Writing Style prev: books/fdp-primer/manual-pages next: books/fdp-primer/editor-config description: Writing Style and some conventions used in the FreeBSD Documentation Project tags: ["writing", "style", "tipos", "one sentence per line"] showBookMenu: true weight: 12 path: "/books/fdp-primer/" --- [[writing-style]] = Writing Style :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 11 :partnums: :source-highlighter: rouge :experimental: :images-path: books/fdp-primer/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[writing-style-tips]] == Tips Technical documentation can be improved by consistent use of several principles. Most of these can be classified into three goals: _be clear_, _be complete_, and _be concise_. These goals can conflict with each other. Good writing consists of a balance between them. [[writing-style-be-clear]] === Be Clear Clarity is extremely important. The reader may be a novice, or reading the document in a second language. Strive for simple, uncomplicated text that clearly explains the concepts. Avoid flowery or embellished speech, jokes, or colloquial expressions. Write as simply and clearly as possible. Simple text is easier to understand and translate. Keep explanations as short, simple, and clear as possible. Avoid empty phrases like "in order to", which usually just means "to". Avoid potentially patronizing words like "basically". Avoid Latin terms like "i.e.," or "cf.", which may be unknown outside of academic or scientific groups. Write in a formal style. Avoid addressing the reader as "you". For example, say "copy the file to [.filename]#/tmp#" rather than "you can copy the file to [.filename]#/tmp#". Give clear, correct, _tested_ examples. A trivial example is better than no example. A good example is better yet. Do not give bad examples, identifiable by apologies or sentences like "but really it should never be done that way". Bad examples are worse than no examples. Give good examples, because _even when warned not to use the example as shown_, the reader will usually just use the example as shown. Avoid _weasel words_ like "should", "might", "try", or "could". These words imply that the speaker is unsure of the facts, and create doubt in the reader. Similarly, give instructions as imperative commands: not "you should do this", but merely "do this". [[writing-style-be-complete]] === Be Complete Do not make assumptions about the reader's abilities or skill level. Tell them what they need to know. Give links to other documents to provide background information without having to recreate it. Put yourself in the reader's place, anticipate the questions they will ask, and answer them. [[writing-style-be-concise]] === Be Concise While features should be documented completely, sometimes there is so much information that the reader cannot easily find the specific detail needed. The balance between being complete and being concise is a challenge. One approach is to have an introduction, then a "quick start" section that describes the most common situation, followed by an in-depth reference section. [[writing-style-guidelines]] == Guidelines To promote consistency between the myriad authors of the FreeBSD documentation, some guidelines have been drawn up for authors to follow. 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. + [NOTE] ==== 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. ==== Do not use contractions:: Do not use contractions. Always spell the phrase out in full. "Don't use contractions" is wrong. + Avoiding contractions makes for a more formal tone, is more precise, and is slightly easier for translators. Use the 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". + For example: + 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:: Do not use redundant phrases. In particular, "the command", "the file", and "man command" are often redundant. + For example, commands: + Wrong: Use the `git` command to update sources. + Right: Use `git` to update sources. + Filenames: + Wrong: ... in the filename [.filename]#/etc/rc.local#... + Right: ... in [.filename]#/etc/rc.local#... + Manual page references (the second example uses `citerefentry` with the man:csh[1] entity):. + Wrong: See `man csh` for more information. + Right: See man:csh[1]. For more information about writing style, see http://www.bartleby.com/141/[Elements of Style], by William Strunk. [[writing-style-guide]] == Style Guide To keep the source for the documentation consistent when many different people are editing it, please follow these style conventions. [[one-sentence-per-line]] == One sentence per line Use Semantic Line Breaks in the documentation, a technique called "one sentence per line". The idea of this technique is to help the users to write and read documentation. To get more information about this technique read the link:https://sembr.org/[Semantic Line Breaks] page. -This is an example which don't use "one sentence per line". +This is an example which does not use "one sentence per line". .... All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. .... And this is an example which uses the technique. .... All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. .... [[writing-style-acronyms]] === Acronyms Acronyms should be defined the first time they appear in a document, as in: "Network Time Protocol (NTP)". After the acronym has been defined, use the acronym alone unless it makes more sense contextually to use the whole term. Acronyms are usually defined only once per chapter or per document. All acronyms should be enclosed using the ` character. [[writing-style-special-characters]] == Special Character List This list of special characters shows the correct syntax and the output when used in FreeBSD documentation. If a character is not on this list, ask about it on the {freebsd-doc}. [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Name | Syntax | Rendered | Copyright | +(C)+ | (C) | Registered | +(R)+ | (R) | Trademark | +(TM)+ | (TM) | Em dash | +--+ | -- | Ellipses | +...+ | ... | Single right arrow | +->+ | -> | Double right arrow | +=>+ | => | Single left arrow | +<-+ | <- | Double left arrow | +<=+ | <= |===