Difference between revisions of "PC-BSD® Wiki:Style Guidelines"

From PC-BSD Wiki
Jump to: navigation, search
(Commandline examples)
Line 193: Line 193:
: Also place a total of exactly one '''<nowiki><noinclude>{{GroupListHeading|tables}}</noinclude></nowiki>''' at the bottom of the page, below any existing <nowiki><noinclude>{{refheading}}</noinclude></nowiki> and above the category links section. Please note a small adjustment to this rule in the ''noinclude block'' section below.
: Also place a total of exactly one '''<nowiki><noinclude>{{GroupListHeading|tables}}</noinclude></nowiki>''' at the bottom of the page, below any existing <nowiki><noinclude>{{refheading}}</noinclude></nowiki> and above the category links section. Please note a small adjustment to this rule in the ''noinclude block'' section below.
==== Emphasis ====
=== Other Text boxes ===

Revision as of 14:32, 15 September 2013

PC-BSD® Wiki:Style GuidelinesProtection (edit): Edited by: Tigersharke



The purpose of defining how pages on the wiki should be created, is to help maintain consistency by having a set standard or model to follow, to enable easier translations of the site into other languages, and allow publishing with less modification. Although this page may not be specifically dedicated to how to edit the wiki, there is plenty of information included here that describe how to use various templates for certain situations. Until a page is developed which does focus on editing the wiki, the information here shall be considered a good start.


The guideline for actual text content may be under continual refinement with frequent additions until nearly complete. In areas that are incomplete or not yet defined, a reasonable default can be taken from the Wikipedia:Manual of Style.

Typographic Conventions

The PC-BSD Handbook uses the following typographic conventions:

bold text: represents a command written at the command line. In usage examples, the font is changed with any command output displayed in unbolded text.
italic text: used to represent device names or file name paths.
bold italic text: used to emphasize an important point.


Highlighted text
In certain circumstances, especially to show revisions such as on the errata page or on this page to more clearly show what to replace, there is the highlight template: {{highlight|text=text}}
In the context of this sentence only this portion of text has the highlight effect.

Redlighted text
This should only have limited use for the sole purpose of adding emphasis to  critical and dangerous  information.

Orangelighted text
This should not be used except in the warning text box, but could aid in emphasis to  details that could cause frustration. 

Language usage and word choice

Use words and phrases with the same meaning; multiple types of sentence structure.

In place of:
  aren't use are not, can't use can not, cannot use can not,

  doesn't use does not, don't use do not, hasn't use has not   haven't use have not, weren't use were not, won't use will not,   you'll use you will, you'd use you would, you're use you are,

  you've use you have.

Brand names
Use web search instead of Google search.

Use proper and precise wording.
Watch closely should be used instead of keep an eye on.
Crashes or fails in place of gets a blue screen of death.
Idioms described on wikipedia.

Use precise rather than colorful or regional terms, however some technical jargon is allowable especially if explained or defined.
Open a browser to pcbsd.org would be used instead of surf to pcbsd.
Slang described on wikipedia.
Jargon described on wikipedia.

Given that some date formats can be problematic: (07-03-2012) Does the author mean July 3rd 2012, or March 7th 2012. The wiki offers a per-user preference for date format. This also formalizes instances of dates which may also aid translations.
{{#dateformat:01 May 2012}} should be used resulting in 01 May 2012 which conforms to each user's preferences.

Uncapped proper names
Some software is officially named in lowercase, yet sentences should usually begin with a capital letter. The solution is to avoid using those special proper names as the word that begins a sentence.

Newness and changes
Especially within a list of updates to the current version, the word now ought to be omitted. By the very nature of pointing out that it is a list of revised features, it implies its relationship to the current documented version and that an adjustment has been made. Where possible the alternative of providing a comparison of the former method, application, or feature which contrasts with the current one is sufficient (and provides an improved explanation in context). Further explanation may be added as in the example below:
The login manager uses PCDM which replaces the former GDM in order to reduce associated dependencies when GNOME is not also installed.

Hypertext Links

Within the text, it is helpful to add a link to topics, pages, and sites to further explain and allow for additional research.

Use a descriptive word or phrase. It can be the general location (page/site) of the link, as long as the link itself is to the specific section (when ever possible). Try not to be too general/generic. Highlight and italic are used for clarity in the examples below.
Replace this: You can find more information about hardware compatibility here.[1]
With this: You can find more information about hardware compatibility on the FreeBSD hardware forum[1].

Replace this: This forum post[1] explains how to properly plug the outlet tube of an inlet drain line.
With this: This PlumberCraft forum post[1] explains how to properly plug the outlet tube of an inlet drain line.

Use an ending slash with any url that leads to a directory or non-file (such as any site name). It is prudent to verify that an adjusted link is valid since some sites do not use extensions for file names. This convention will aid with consistency and help to eliminate technically different but effectively identical URLs.
This is a valid url: http://forums.freebsd.org
Url with proper syntax on this wiki: http://forums.freebsd.org/
Example of a url that ends with a file name: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/sound-setup.html

The URL is within the PC-BSD wiki. The template local assists with localization of the internal links. The link URL will attempt to use a localized one of the form pagename/en where 'en' would be the language of the current page. The link name will attempt to use the localized name where the link is displayed. The separation of the anchor from the base URL allows it to be localized independently.
{{local|link=page name}}
{{local|link=page name|alternate text}}
{{local|link=page name|anchor=page sub-heading|alternate text}}

The URL is for a location outside of wiki.pcbsd.org. Most places where an external link may be used, there is alternate text shown, which means for a printed handbook, there must be a footnote to provide the actual URL. Those rare places that do not provide alternate text but show the actual URL, do not need the citelink. If the link text is to be bold or italic or both then the modifier characters must be directly around the alternate text and not around the entire citelink phrase below.
For the link use {{Citelink|url=complete URL|txt=alternate text}}
Also place a total of exactly one <noinclude>{{refheading}}</noinclude> at the bottom of the page, above the category links section.

Special External (standard)
The URL is for a site not part of the PC-BSD wiki, but has a defined shortcut such as for wikipedia.
{{Citelink|shortcut|url=page URL|txt=alternate text}}
Example: [http://en.wikipedia.org/wiki/faq/ faq on wikipedia] becomes {{citelink|wikipedia|url=faq|faq on wikipedia}}

Special External (abbreviation)
The URL would otherwise be obscenely long especially due to defining languages the external site has localized.
{{Citelink|shortcut|txtAb=alternate text}}
Example of abbreviation use: [https://creativecommons.org/licenses/by/3.0/deed.en Creative Commons] would be
{{citelink|url=https://creativecommons.org/licenses/by/3.0/deed.{{testLangURL|es|es_ES|ca|de|eo|fr|id|it|hu|no|nl|pl|pt|pt_BR|fi|sv|is|el|ru|uk|zh|zh_TW|ko}}|txt=Creative Commons}}
but due to txtAb is now {{citelink|ccby3|txtAb=Creative Commons}}

Special Characters

Traversal of menus or windows
use an arrow (➜)
Replace this: PC-BSD control panel -> System manager -> System packages
With this: Control Panel System ManagerSystem Packages
This is a unicode UTF-8 character but may appear gibberish in other charsets such as IS0 8859-1.

PC-BSD®, AppCafe®, and Warden® are registered trademarks and the ® symbol must appear next to these terms except when the term is used as a command or in command output.

template:RM produces ® via {{RM}} which is simply an equivalent in place of typing the specific character.
template:r produces ® via {{r}} which is a symbol that is 50% of the size it would be in that context and in superscript position.
 WARNING  Special care needs to be taken because the two are not equivalent. NavHome, NavHeader, and SwapTitle have custompagename that may be assigned content that includes {{r}} but where that is used, custompagecategory must be defined an equivalent content that includes {{RM}}. Internal links must include {{RM}} for the page name portion, but may include {{r}} for the displayed text.

Named visual objects

Often the documentation within the handbook will describe a series of steps that includes clicking upon a button. In other places, the handbook may indicate the name of a window or folder or other object on the screen.

These items could be further emphasized, but their names must be within quotes.
Example: Click on the "Submit" button along the lower edge of the "Compose response" window.

Special Visual entities

Commandline examples

Frequently in the handbook we provide a series of commands or shell output. For these situations, use template:txtbox. Such content should be formatted for a width of 80 characters (spaces included).

Replace this
(The wiki method: leftmost character per line is a space.)
Cause a box to enclose the text by starting the sentence with a space, however this has a small problem with keeping the text inside the box. For whatever reason, the text extends out of the dashed lines of this box, to the right.

With this
A much improved variation of that above method also encloses the text within a similar box. Even though the text is a short paragraph of four sentences in length, it does not have the same flaw as before. The text is neatly contained within the dashed lines of the box, and also does not require the initial space character at the start of the first sentence. If that character were included, it would display with two nested boxes. The exact wrap style can be determined when invoked; this box uses 'pre-line' style formatting.
Text to the right of the box is also possible. This is the txtbox template which facilitates a better result without adding a lot of extra typing. Further details including the list of format identifiers are on the template page.


An addition of a class="spiffy_table" which further simplifies creation (as shown below), the init template includes it transparently. Including a caption places it into the tables group list.

Table  Is there no version? of comparison [Tables 1]
inline style via template method CSS style method Combination
This is rather verbose and was more of a brute force method to get the job done. Every line needed a row number which is helpful for readability but also correlated to coloration: odd=white, even=grey. -obsolete- Tables should be converted from this to the other method(s). Clearly this method involves the least typing to produce a good result. This mixed method is also possible. Including tbl-title allows for defining width.
{{tbl-init|align=center|caption=1a. The caption
{{tbl-title|column title}}

{{tbl-cell|row=1|The content}}
2|The content}}
{{tbl-init|caption=1a. The caption}}
!column title
The content
The content
{{tbl-init|caption=1a. The caption}}
{{tbl-title|width=32%|column title}}
|The content
|The content
Also place a total of exactly one <noinclude>{{GroupListHeading|tables}}</noinclude> at the bottom of the page, below any existing <noinclude>{{refheading}}</noinclude> and above the category links section. Please note a small adjustment to this rule in the noinclude block section below.

Other Text boxes

Often we need to specifically call attention to a particular caveat, or other tidbit of information that is not mission critical.
NOTE: This is an example that spans the width of the page.{{note|text}}
NOTE: Include an icon for larger notes by assigning the text to icon64 when the template is used, such as {{note|icon64=text}}. This icon is the classic tie a string around your finger to help remember, the green triangle is used in hopes of implying that you can continue safely. As you can see with this text box, the message content neatly wraps around the icon. This wrapping will continue neatly around the icon, even when there is sufficient text that the position of the lines in the message fall below the it. The same effect with 64px icons and wrapping text content works for the other two icon message boxes described below.

Some instructions have frustrating or annoying consequences and therefore should be emphasized.
 WARNING  The simple quick one-line comment. Use {{warning|text}} for this.
WARNING A verbose and descriptive warning. The concept behind the icon is that something may have been missed, stop and check, investigate. {{warning|icon64=text}}

Some instructions are critically dangerous and may result in serious harm if a mistake is made.
 DANGER!  The simple quick one-line comment. It is invoked by {{warning|text}}
DANGER! The text content probably should default to bold or bold and italic. This icon hopes to clearly indicate possible damage to the PC involved. {{danger|icon64=text}}

Topics structure

This will directly relate to headings, but since headings on individual pages are used in a somewhat non-uniform way (due to the appearance of each level of heading), this will apply to a naming convention used with the Table of Contents.

Examples in context

8. Control Panel <-- Macro Topic (Also wiki page and "level 1")

8.1 EasyPBI <-- Topic (Also wiki page and "level 1")

(Below are hidden on the wiki TOC but get shown in the published handbook html - All sub-page level)

8.1.1 Creating a PBI Module <-- Micro Topic Build the Module <-- Nano Topic Test and Fine-Tune the Module pbi.conf <-- Pico Topic Resources Desktop/Menu Entries External-Links

(Below is not known to have been used anywhere but if they were to exist this is how they would be used/named) Example of external link <-- Femto Topic ("level 5") This is the example <-- Atto Topic ("level 6")



There are two types of bullets in use:

  1. A bulleted list which begins uppercase. Whether or not it ends in punctuation depends upon the size of the list. For example:
    • the What's New in 9.1 list uses sentences to describe the features so ends in a period. Use this type of list when the list includes a description large enough to warrant at least one sentence.
    • the Minimum Hardware Requirements list uses few words per item. Since the individual items do not warrant a sentence, this type of list does not end in a period.
  2. A bulleted list which begins with bolded text (typically the name of a menu item). The bolded section is capitalized to match the name of the menu item and followed by a colon (:). The sentence following the colon begins lowercase and should be worded so that the bolded item is the beginning of the sentence. An example is:
    Size on Disk: indicates the amount of space being used by the jail.
    In this example, the menu item appears as "Size on Disk" (mix of upper/lowercase), "indicates" is lowercase and is worded so that it reads as one sentence (including the name of the menu item). Because it is a sentence, it ends with a period.

Left from prior guideline
To ensure that the PDF and EPUB versions format correctly, use a hard enter between the items in a bulleted list.
Suggestion used in revision above, is addition of <br>. This still needs verification whether a hard enter or <br> are needed.


The information should first be placed in logical order, followed by quality or significance, then sorted in alphabetical order, next by chronological order, and finally by ordination. It may be noted that the entire collation section follows logical order, due to the order described in the first sentence. Examples below are taken from the PC-BSD Users Handbook#Table of Contents. The Errata page shows how chronological and ordinal organization may be used together. Using wiki markup in place of text (such as for numbering schemes) might allow for automatic charset substitution in relation to translations.

Putting things in order of precedence; from first task to last task, or first item naturally listed to last item.
  1. Introduction
  2. Pre-Installation Tasks
  3. Installing PC-BSD
  4. Post Installation Configuration and Installation Troubleshooting

Quality or significance
Organizing according to the importance of the item or its membership in a specific group type.
This is most visible with groups, such as Supported and unsupported desktops. In the Alphabetical example, the first four would seem out of order if the entire set of desktops were included, as below.
Window Maker

Organizing items by name according to the alphabet.

Placing items in order according to date.
This is distinction primarily relates to historical and archival purposes.
Items are placed in reverse order, most recent first and oldest last.

The items are listed according to number.
Examples are Handbook page and chapter numbers, step-by-step instruction where numbered incremental actions are listed.
Elements are organized from smallest to largest value, or first to last step (similar to logical).
Wiki markup
# first text
# second text
  1. first text
  2. second text


It is important that the images included in the wiki, especially the handbook portion, be consistent and of a quality that would be acceptable in a professional publication. (Note: Further refinement of images should be done, including a template for images that may shorten or clarify their inclusion. There are features that exist for images that also modify the page layout which are currently too wikipage specific to describe here in general terms.)



Single windows

Multiple windows

These may be within the same image or screenshot if the purpose is to show one task.


[[File:File:GNOME2-2.png|thumb|393px|'''Figure 6.1a: GNOME2 Desktop on a PC-BSD® System''']]
<div style="overflow: hidden">[[File:Login2.jpeg|left|thumb|393px|'''Figure 4.8c: Login Menu with User Selected''']][[File:start1.png|right|thumb|393px|'''Figure 4.8d: PC-BSD® Getting Started Screen''']]</div>

Scalable Dimensions

Table of Acceptable 4:3 screens
Resolution Multiplier
800x600 1.00
1024x768 1.28
1152x864 1.44
1200x900 1.50
1280x960 1.60
1400x1050 1.75
1440x1080 1.80
1600x1200 2.00
1920x1440 2.40

Capture tips



All pages that use templates: SwapTitle, NavHome, and NavHeader, are automatically added to a category of their pagename (or custompagename where one is defined).

Each wiki page (ie, GNOME2) and image page (ie, File:Stub-icon.png) should be a member of at least one category.
The category chosen may be determined by the description given on the individual category pages.

Place the category link at the bottom of the page, contained within the between the <noinclude> block. The first category listed should be the largest group the page belongs to, followed by increasingly specific categories. Category names should be capitalized the same as the pages involved, or each individual word has its first letter capitalized. Some templates can auto-categorize pages into their page title category.

The categories themselves should have some sort of explanation to guide their use.

Page structure

Each handbook page contains a 3-icon navigation panel across the top,
<noinclude><translate>{{NavHeader|back=page before current|forward=page after current}}</noinclude>
while other pages linked from the main page contain a simplified version.

With relation to new pages that have minimal content, a stub warning is included to enhance visibility and aid with community involvement.

Used in locations of the wiki markup that purposely and specifically do not follow the guideline, or places where reminders or explanations are needed or useful.
<!-- comment text -->

The <noinclude> block
Each page should contain a group of category links at the bottom, along with a Refheading and GroupListHeading as applicable (may be enclosed with comment markers if not yet needed). No further text or spaces following, though in some instances a comment is present with nothing following it. The categories included here should become more general as the list continues downward, an example series in order would be: GNOME2, Desktops, Handbook. Although 'GNOME2' would be auto-included by NavHeader. The translate tag allows the page to be marked for translation, while the languages tag determines where links to translations of the current page will be displayed.

{{Refheading}} {{GroupListHeading|group=tables}} [[category:category 1]] [[category:category 2]] </translate> <languages/>



Generally, the headings on a page help to outline and organize the content. It should also be noted that having identical headings or sub-headings within the entire wiki can cause trouble with future editing or navigation, and should be avoided. Include an action word or phrase or otherwise differentiate between the two locations, even if they are discussing the same content, the purpose in each case is not likely identical. Further investigation into the dead-tree/published version(s) needs to be done so the wiki version might hope to match or have a consistent header structure if visually different. (If a certain heading style is preferred though it does not match the guide below, then perhaps adjustments to the wiki site css need to be made.)

Page title

= Page title =
This level should not be used within a page. If there is need for this level within the content of the page, then it shall be the location of a break into a new page of that title. Here is where an introductory paragraph explaining the topic or feature given by the page name.

Level 2

== Level 2 ==
Often this level is skipped in favor of the next - likely indicating css changes should be made.

Level 3

=== Level 3 ===
(Since the level above gets skipped) Here is where the first major step of a process is mentioned, or the main characteristic of the feature is described.

Level 4

==== Sub-heading ====
This level exists but is generally unused currently.

Level 5

===== Level 5 =====
Usually the definition markup (;) is used in place of this header, such as the following:

The above term is defined here.
Level 6

====== Level 6 ======
This level exists but is generally unused currently.



  1. 1.0 1.1 1.2 1.3 http://forums.freebsd.org/forumdisplay.php?f=32

 Translator:  Please update the last element on this page, and/or locate the {{groupListHeading|group=tables}} line, replace that with {{GroupRefHeading|{{putCommon|19}}}}

Cite error: <ref> tags exist for a group named "Tables", but no corresponding <references group="Tables"/> tag was found
Retrieved from ‘http://wiki.pcbsd.org/index.php?title=PC-BSD®_Wiki:Style_Guidelines&oldid=34456
Personal tools