PC-BSD® Wiki:Style Guidelines

From PC-BSD Wiki
Revision as of 02:27, 20 December 2013 by Tigersharke (Talk | contribs)

Jump to: navigation, search
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 describes 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. A template quick reference or an editor's stylesheet may also be helpful.


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.

Other Emphasis

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. This will increase interest and also by use of synonyms will improve the chance that the text will be understood, especially with regard to translations or non-native English readers.


  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

Since some brand names may not always exist or are potentially unavailable/unknown, we must use a more descriptive word or phrase rather than a company or brand name for the item.

Use web search instead of Google search.
Use cotton swab rather than Q-tip.


Each language has its own idioms which are born from the context of that culture. It is much clearer and more universally understood if such phrases are avoided.

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[1].


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


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.[4]
With this: You can find more information about hardware compatibility on the FreeBSD hardware forum[4].

Replace this: This forum post[4] explains how to properly plug the outlet tube of an inlet drain line.
With this: This PlumberCraft forum post[4] 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 template:traverse result:

        Control Panel → System Manager → System Packages

{{traverse|Control Panel|System Manager|System Manager/{{release}}#Install.2FUninstall Desktops and System_Components|here=System Manager|t3=System Packages}}
Caveat:  this is not yet 'version' friendly 


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, UseTOC, and SwapTitle have title that may be assigned content that includes {{r}}. Internal links must include {{RM}} for the page name portion, but may include {{r}} for 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.

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? 1a. Comparison of table syntax [Tables 1]
Frequently used wiki markup (replace this) Best method leverages CSS (with this)
Such bare-bones approach may be less obvious and implementation frequently omits features. This method may involve slightly more typing but produces a very sharp result such as this table itself and added the feature of a table index.
!column title
|The content
|The content
{{tbl-init|caption=1a. Comparison of table syntax}}
!Frequently used wiki markup (replace this)
!Best method leverages CSS (with this)
|The content (obsolete table markup)
|The content (replacement table markup)
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.

Special Text boxes

Some comments within the content of the page need or should be clearly separated from the rest of the text to both give better context and improved awareness.


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 is simply text.{{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 remains to the right of the icon and is of a somewhat smaller size than the surrounding page. This right indent will continue with the icon centered vertically, even when there is sufficient text that the column of lines in the message are much larger than the height of the icon. The same effect with 32px, 48px, or 64px icons and text content works for the other two icon message boxes described below. To apply the other sizes of icon, simply assign the text to 'icon32' or 'icon48' as was done for 'icon64' here. It may make sense to use a smaller icon for smaller amounts of text, however, normally the box will adjust to match both the page space and content size. A further option may be used to cause the box to position itself to the right side of the page, if an additional field of class=rightfloat is included with the invocation such as {{note|class=rightfloat|text content}}. Various formatting within the box is also possible.


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 {{danger|text}}
DANGER! The text content probably should default to a surfeit of bold or bold and italic. This icon hopes to clearly indicate that possible damage to the PC may be 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


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.

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.

Since the wiki markup does not prompt for an alt tag along with other deficiencies, there will need to be an 'image' template which will replace the current [[File:blah.png|thumb|'''caption''']] method.
 This is a warning that another site-wide change will be coming. 



  • Portable Network Graphic (png).
  • Must limit to a maximum size of 800x600, this allows the entire image to remain visible even on a 1024x768 screen size.
  • Use background transparency where things such as irregularly shaped icons or rounded window corners are used.
  • Avoid window themes that include translucency or transparency of window content, title, or decorations. These can lead to less clear or unreadable titles, decorations, or content.
  • Identify each graphic with a Figure number consisting of the section number of the page followed by a letter, alphabetically with 'a' for the first graphic and 'b' for the second and so forth. Directly after the letter, place a colon and a brief description, preferably more concise than its mention within other text on the page.
    Example: Figure 6.1a: GNOME2 on PC-BSD
  • Include an image on a page with the following syntax:
    Example: [[File:Important.png|thumb|393px|caption]]

Single windows

  • Include the whole window frame and its title bar.

Multiple windows

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

  • Crop to a box that contains both windows with entire window borders intact.
  • Windows may overlap only if necessary details as provided by wiki text are not hidden.
  • Must include in the image: options, button labels, window titles, and any other detail that allows the step-by-step to be easily followed without surprises.


  • Must limit to a maximum size of 800x600, this allows the entire image to remain visible even on a 1024x768 screen size.
  • If the content is text and has no images, such as console output, then transcribe the text into a txtbox (Do NOT use an image).
  • Include a single image on a page with the following syntax:
[[File:File:GNOME2-2.png|thumb|393px|'''Figure 6.1a: GNOME2 Desktop on a PC-BSD® System''']]
  • Place two images side by side on a page with this syntax:
<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

  • An initial image of other 4:3 ratio can be scaled down to 800x600 without serious distortion, but care must be taken that text remains legible.

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

  • Begin with an unmodified/default desktop configuration- including only the installed software to be discussed.
  • Emphatically recommended to use Virtual Box with a desktop of 4:3 ratio, Host name: Demo System, Username: PC-BSD_User, which would allow for consistency, universality, and genericness.
  • Use a white desktop background to easily capture individual windows or icons.
  • Expand the Virtualbox window to be larger than the enclosed desktop (desktop will be surrounded with a white frame).
  • The excess white background of cropped images is easily selectable by contiguous shape or color. Next, either invert the selection to cut/copy then paste into a new canvas, or delete the selection so it will be replaced with the alpha transparency.
  • When cropping selections, use the zoom tool to enlarge the work area to prevent loss of details or enable addition of transparency for rounded corners.
  • Where possible, resize windows so that their entire content can be shown without scrollbars.



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. http://en.wikipedia.org/wiki/Idiom
  2. http://en.wikipedia.org/wiki/Slang
  3. http://en.wikipedia.org/wiki/Jargon
  4. 4.0 4.1 4.2 4.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
Personal tools