Editing Documentation/Maemo Documentation Guidelines/General writing conventions

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

This section describes the general writing conventions for Maemo documentation. The writing conventions are based on ''Nokia Brand Book'' <ref name=r6>Nokia Brand Book. http://brandbook.nokia.com</ref> and ''Nokia A-Z Marketing Language Guide'' <ref name=r5>Nokia A-Z Marketing Language Guide. http://brandbook.nokia.com</ref>.

== Language to be used ==

Maemo documents are written in UK English.

If you need to check the spelling of some specific words, use Collins English Dictionary. For more information, use the ''Collins English Dictionary'' <ref name=r2>Collins English Dictionary. http://www.collinslanguage.com</ref>.

== Headings ==

Maemo documents use the five heading styles and levels described in table 3.1.

{| class="wikitable"
|+ Table 3.1: Heading styles and levels
|-
! Heading Style
! Level
! Numbering
|-
| <code>\chapter{Chapter title}</code>
| 0
| (a)
|-
| <code>\section{Section title}</code>
| 1
| (a.b)
|-
| <code>\subsection{Subsection title}</code>
| 2
| (a.b.c)
|-
| <code>\subsubsection{Subsubsection title}</code>
| 3
| (a.b.c.d)
|-
| <code>\textbf{Paragraph title}</code>
| 4
| (a.b.c.d.e)
|}

Each level 0 chapter (a) must start from a separate page.

Each level 1 section (a.b) must have a generic "a.1 Introduction" section (as the first section). In the introductive section, add links to example applications used and API docs referred to in the section.

Level 3 subsubsections (a.b.c.d) are the lowest level included in the table of contents.

If the purpose is NOT to have a section number and NOT to include section to the table of contents, add an asterisk (<nowiki>*</nowiki>) to the end of the header tag. For example, <code>\subsection*{Example title}</code> creates a level 2 heading without numbering and without adding it into the table of contents.

It is also possible to create level 4 paragraphs (a.b.c.d.e) but no lower than that. A level 4 paragraph has the following special features by default:

* it is not included in the table of contents
* it does not use section numbering
* it cannot be referenced from the base text

For more information, see chapter [[#Creating cross-references and links]].

== Lists ==

List types can be divided into three categories:

; '''Unordered lists'''
: are also known as bullet lists. Use unordered lists when the specific order of the list items is not relevant.
; '''Ordered lists'''
: are also known as numbered lists. Use ordered lists when the order of the list items is relevant.
; '''Step lists'''
: are a subcategory of ordered lists, but used specifically for providing instructions on how to complete a procedure. Introduce each step list with an introductory sentence, using the syntax: ''To &lt;do&gt; &lt;something&gt;''.

Keep lists simple. Do not include code examples or other complex items like tables or figures as a part of a list item. Avoid using nested list.

== Tables ==

Keep tables as simple as possible. Use figures instead of complex tables.

Do not create complex structures, such as table cells including other elements than text. Avoid using multi-column cells for other purposes than creating subheadings for the table. If complex tables are needed create them outside LaTeX as images.

Basic instructions for table creation in LaTeX can be found from [http://en.wikibooks.org/wiki/LaTeX/Tables WikiBooks LaTex/Tables].

Each table must have a title that can be referenced.

== Figures ==

When creating figures, it is recommended to use free graphics tools like [http://www.inkscape.org/ InkScape] or [http://www.gimp.org/ Gimp].

Provide figures in a high resolution format. If needed, high resolution figures are scaled down for HTML and PDF usage.

{|
|-
| [[Image:dialog-information.png]]
| '''Note:'''  Screenshots can be low resolution if high resolution figures cannot be created.
|}

For books and printing houses, resolution must be high enough. The recommendation is 300 dpi.

Use either PNG or JPEG format. PNG is recommended.

EPS format is not allowed in figures, because it cannot be used in PDF and HTML documents. For more information, see [http://en.wikibooks.org/wiki/LaTeX/Importing_Graphics WikiBooks LaTex/Importing Graphics].

Basic instructions for figure creation in LaTeX can be found from [http://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions WikiBooks LaTex/Floats, figures and Captions].

Each figure, including screen shots, must have a title that can be referenced.

== Highlighting important text ==

Use ''Italics'' to highlight important words in base text, apart from command line examples and function or file names. Do not use '''Bold''', or TextRaw for highlighting.

Do not use ''Italics'' for the following items:

* sentences or chapters
* product or component names (capitalize first letters instead of using formatting)
* paragraph titles (use '''Bold''' instead)
* example code and file names (use TextRaw instead)

Use Italics (at least) for the following items:

* important words that need special attention from the reader
* document names (with reference to Maemo Bibliography database)
* For more information on highlighting a whole sentence or chapter, see chapters [[#Highlighting example code]] and [[#Creating notes]]

== Highlighting example code ==

Use TextRaw or <code>Verbatim</code> to highlight command line examples and function or file names in base text. Do NOT use ''Italics'' for these. The difference between these two is that TextRaw allows normal LaTeX commands inside text will be ignored and handled as plain text.

Use TextRaw or <code>Verbatim</code> to highlight the following items:

* paths and file names
* source code examples
* command line examples
* screen output examples
* environment variables
* domain names and IP addresses

Use TextRaw for source code examples. Names need to be written exactly as in source code, for example, ThumbButton, SmallFont, PANGO_SCALE_SMALL, and ButtonTextColor.

Use TextRaw for command line examples and file names, for example, sources.list, /opt/bin/share, and apt-get install maemo-python-env.

Use references to the source code names in the following way:

* For user to be able to cancel operation without saving modified data you need to add ThumbButton for your dialog.

For more information, see chapters [[#Highlighting important text]], [[#Code listings]], and [[#Command line and screen output examples]].

== Highlighting UI element names ==

Use '''Bold''' font to highlight user interface component caption names in text. For example, if you need to refer to a UI button with the caption '''Cancel''' use the caption '''Cancel''' as the element name and use '''Bold''' to highlight the name. Do NOT use ''Italics'', TextRaw or <code>Verbatim</code> for highlighting UI element names.

Use TextRaw or <code>Verbatim</code> only for referring to source code name of the UI element.

Use references to the UI element names in the following way:

* To cancel operation without saving modified data, press button '''Cancel''' in dialog.

For more information, see chapters [[#Highlighting important text]], [[#Code listings]], and [[#Command line and screen output examples]].

== Creating notes ==

Notes are used in documentation to make the reader pay attention to important issues that have to be taken into consideration. Do not add a note as a part of the body text. Instead, create each note on a separate row using NoteBox:

{|
|-
| [[Image:dialog-information.png]]
| '''Note:'''  This is an example of a note.
|}

Before using a NoteBox consider whether using ''Italics'' is enough to highlight the issue in the base text. Use NoteBox only for very important issues and avoid ending a section with it.

== Creating cross-references and links ==

All Maemo documents must use the same LaTeX bibliography database. References added to the document from the bibliography database are added to the bibliography list automatically.

Use Maemo bibliography database references in the following way:

* For more information on Nokia Brand, see document ''Nokia Brand Book'' <ref name=r6/>.

To allow level 1 sections (a.b) to be reused in several different documents:

* Do not link between level 1 sections (a.b) within a document. For example, do not make links from level 1 section (x.y) to subsections, tables, or figures located in another level 1 section (x.z).
* Linking within level 1 section (x.y) is allowed.

Each level 1 section (a.b) must have a generic, introductive section (a.1 Introduction). The introductive section should contain:

* A short introduction text about the purpose of the section.
* Links to all example applications used in the section. The only allowed example links are to the [https://garage.maemo.org/svn/maemoexamples/ Maemo examples project] in Garage.
* Links to all API docs referenced in the section. Links out of maemo.org are allowed for API docs.

If section Y referenced from the text is in the same level 1 section (a.b) as the text itself, create a section number link to section Y.

Use cross-references with section number link between sections in the following way:

* For more information on topic X, see chapter [[#Creating cross-references and links]].
* For more information on topic X, see figure [/node3.html#fig:documentation_guidelines-introduction-n900 1.1].
* For more information on topic X, see table 3.2.

If section Y referenced from the text is not in the same level 1 section (a.b) as the text itself, create a textual reference instead by using the chapter name in quotes. Do not use chapter numbers in textual references.

Use textual references between two level 1 sections (a.b) in the following way:

* For more information on references, see chapter "How to write text references".
* For more information on references, see figure "How to write text references".
* For more information on references, see table "How to write text references".

Use Maemo bibliography database for references to other documents.

== Trademarks ==

To check the correct spelling of common Nokia trademarks and product names, see chapter [[#Product names]].

== Acronyms ==

To check the correct spelling of common Nokia trademarks and product names, see chapter [[#Product names]].

== Clear and concise language ==

Use clear and concise language. Use the imperative in instructions, and avoid using the passive voice or empty expressions, if possible. See examples about how to use clear language expressions in table 3.2.

{| class="wikitable"
|+ Table 3.2: Examples for clear language
|-
! Problem
! Incorrect
! Correct
|-
| There is/are as an empty expression.
| There is a possibility to do X.
| You can do X.
|-
| It is as an empty expression.
| It is possible to install X.
| You can install X.
|-
| Have/has as passive voice or an empty verb.
| X has the option of including Y.
| X can include Y.
|-
| Be/are/been as passive voice.
| This is done by installing X.
| For this, install X.
|-
| Using the future tense.
| A window will open.
| A window opens. Instead of the future tense (will), use the present tense.
|-
| Providing options to the reader.
| You can do this or that.
| Do this. To be as clear as possible and to avoid any ambiguity, do not give the user several options about what they can do. Be as direct as possible.
|-
| Redundant politeness.
| Please.
| Please is an empty expression that can usually be omitted.
|-
| Gender-specific language.
| He/she.
| Instead of the gender-specific terms he or she, use the more neutral they.
|-
| Conditional.
| Would.
| Using the conditional gives the impression of uncertainty. Avoid the conditional, and use the present tense instead. If this is not possible, use can.
|-
| Conditional.
| May/might.
| Using the conditional gives the impression of uncertainty. Avoid the conditional, and use the present tense instead. If this is not possible, use can.
|}

== Conjunctions ==

Use properly the conjunctions given in table 3.3.

{| class="wikitable"
|+ Table 3.3: Proper usage of conjunctions
|-
! Incorrect
! Correct
|-
| since
| because
|-
| as
| because (except when used as synonymous to like)
|-
| when
| because (not instead of if)
|}

== Shortkeys ==

Use CTRL+C to refer to pressing the control and c keys together. Use the same TextRaw text formatting for all Shortkeys in base text as for command line examples inside text.

== Abbreviations ==

To avoid sounding too casual, do not use apostrophes to mark possession or to form plural nouns. For more details, see table 3.4.

{| class="wikitable"
|+ Table 3.4: Proper usage of abbvreviations
|-
! Incorrect
! Correct
|-
| <nowiki>*'ll</nowiki>
| instead of the future tense, use the present tense.
|-
| <nowiki>*'re</nowiki>
| write a two separate words, for example there are
|-
| <nowiki>*'s</nowiki>
| instead of device's platform, write device platform or use the preposition of to form the possessive: the platform of the device
|}

== Code listings ==

Separate source code example listings that are not part of the base text must fulfill the following requirements:

* Code example needs to be inside a listing box that separates it from the base text.
* Listing box should be connected to the surrounding base text with a reference.
* Listing box must not have Caption or Label, e.g. listings cannot be refered from text.
* Each piece of source code used in the example must be taken from an official example application in a Garage project. The validity of all such code examples must be tested.
* All source code examples must use source code highlighting for better readability.
* All source code examples must include comments explaining the functionality.
* If the example code used is longer than 50 lines it is recommended (but not required) to include also copyright and licensing information in the beginning of the example code.

{|
|-
| [[Image:dialog-information.png]]
| '''Note:'''  Each code example in a Garage project copyrighted by Nokia must use MIT-style licence to allow the free use of the example code.
|}

Source code example types supported for listings are C/C++, CSS, HTML, Java, JavaScript, Latex, Pascal, Perl, PHP, Postscript, Python, Ruby, SQL, Tcl, Properties files, Makefile, XML, Log files, Ini files, Shell scripts and more.

The following is an example of how code listings can be connected to the surrounding text:

Example code below describes how to create...

<source lang="c">
/*
* example_source.c, an example source code for kernel module
*
* Copyright (C) 2010 Nokia Corporation. All rights reserved.
*
* This maemo code example is licensed under a MIT-style license,
* that can be found in the file called "COPYING".
*
*/

#include <linux/module.h> /* needed by all kernel modules */
#include <linux/init.h> /* needed for custom init/exit functions */
#include <linux/kernel.h> /* needed for KERN_ALERT macro */

/* Special macro to indicate license (to avoid tainting the kernel) */
MODULE_LICENSE("Dual MIT/GPL");

static int hello_init(void) {
printk(KERN_ALERT "Hello, world\n"); /* top priority message */
return 0;
}

static void hello_exit(void)
{
printk(KERN_INFO "Goodbye, world\n");
}

/* macros to mark modules init/exit funcs (run on insmod/rmmod) */
module_init(hello_init);
module_exit(hello_exit);
</source>

Example given above is the simplest way to implement...

Avoid ending a section with a listing box.

== Command line and screen output examples ==

Separate command line and screen output examples that are not part of base text and are not source code examples must fulfill the following requirements:

* Example needs to be inside a GrayBox that separates it from the base text.
* Example box does NOT have a title and CANNOT be referenced.
* Example does NOT get automatic source highlighting.
* Example box should be connectied to the surrounding base text.

The following is an example of how a command line example within a GrayBox can be connected to the surrounding text (notice that an empty line must be given before GrayBox).

Following commands show how to...

$ COMMAND LINE EXAMPLE IS HERE
 $ ANOTHER COMMAND LINE IS HERE

Commands given above can be used also in...

Avoid ending a section with a GrayBox.

== Product names ==

The following is an initial list of Maemo product names in alphabetic order:

* Bora
* Chinook
* Debian
* Diablo
* Fremantle
* Gregale
* Harmattan
* Maemo
* maemo.org
* Maemo C++
* Maemo ESbox
* Maemo Flasher-3.5
* Maemo Host PC Connectivity
* Maemo Mica Framework
* Maemo PC Connectivity
* Maemo PluThon
* Maemo Python
* Maemo Qt4
* Maemo SDK
* Maemo SDK Virtual Image
* MaemoPad
* Mistral
* N800
* N810
* N810 WiMAX Edition
* N900
* Nokia 770
* Scirocco
* Scratchbox

The following table 3.5 presents the correct way to spell some product names:

{| class="wikitable"
|+ '''Table 3.5:''' Proper usage of product names
|-
! Incorrect
! Correct
|-
| Maemo SDK(+)
| Maemo SDK
|-
| the Maemo SDK
| Maemo SDK
|-
| sbox
| Scratchbox
|-
| Maemo Virtual Image
| Maemo SDK Virtual Image
|-
| N810 Wimax
| N810 WiMAX Edition
|}

== References ==

[[Category:Documentation]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Templates used on this page:

Template:Ambox (view source) (semi-protected)

Retrieved from "http://wiki.maemo.org/Documentation/Maemo_Documentation_Guidelines/General_writing_conventions"

Personal tools

Navigation

Views

Editing Documentation/Maemo Documentation Guidelines/General writing conventions

@@ Line 45: / Line 45: @@
 Level 3 subsubsections (a.b.c.d) are the lowest level included in the table of contents.
-If the purpose is NOT to have a section number and NOT to include section to the table of contents, add an asterisk (<code>*</code>) to the end of the header tag. For example, <code>\subsection*{Example title}</code> creates a level 2 heading without numbering and without adding it into the table of contents.
+If the purpose is NOT to have a section number and NOT to include section to the table of contents, add an asterisk (<span><font face="monospace"><nowiki>*</nowiki></font></span>) to the end of the header tag. For example, <code>\subsection*{Example title}</code> creates a level 2 heading without numbering and without adding it into the table of contents.
 It is also possible to create level 4 paragraphs (a.b.c.d.e) but no lower than that. A level 4 paragraph has the following special features by default:
@@ Line 74: / Line 74: @@
 Do not create complex structures, such as table cells including other elements than text. Avoid using multi-column cells for other purposes than creating subheadings for the table. If complex tables are needed create them outside LaTeX as images.
-Basic instructions for table creation in LaTeX can be found from [[wikibooks:LaTeX/Tables|WikiBooks LaTex/Tables]].
+Basic instructions for table creation in LaTeX can be found from [http://en.wikibooks.org/wiki/LaTeX/Tables WikiBooks LaTex/Tables].
 Each table must have a title that can be referenced.
@@ Line 84: / Line 84: @@
 Provide figures in a high resolution format. If needed, high resolution figures are scaled down for HTML and PDF usage.
-{{ambox|text=Screenshots can be low resolution if high resolution figures cannot be created.}}
+{|
+|-
+| [[Image:dialog-information.png]]
+| '''Note:'''  Screenshots can be low resolution if high resolution figures cannot be created.
+|}
 For books and printing houses, resolution must be high enough. The recommendation is 300 dpi.
@@ Line 90: / Line 94: @@
 Use either PNG or JPEG format. PNG is recommended.
-EPS format is not allowed in figures, because it cannot be used in PDF and HTML documents. For more information, see [[wikibooks:LaTeX/Importing_Graphics|WikiBooks LaTex/Importing Graphics]].
+EPS format is not allowed in figures, because it cannot be used in PDF and HTML documents. For more information, see [http://en.wikibooks.org/wiki/LaTeX/Importing_Graphics WikiBooks LaTex/Importing Graphics].
-Basic instructions for figure creation in LaTeX can be found from [[wikibooks:LaTeX/Floats,_Figures_and_Captions|WikiBooks LaTex/Floats, figures and Captions]].
+Basic instructions for figure creation in LaTeX can be found from [http://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions WikiBooks LaTex/Floats, figures and Captions].
 Each figure, including screen shots, must have a title that can be referenced.
@@ Line 98: / Line 102: @@
 == Highlighting important text ==
-Use ''Italics'' to highlight important words in base text, apart from command line examples and function or file names. Do not use '''Bold''', or <code>TextRaw</code> for highlighting.
+Use ''Italics'' to highlight important words in base text, apart from command line examples and function or file names. Do not use '''Bold''', or <span><font face="monospace">TextRaw</font></span> for highlighting.
 Do not use ''Italics'' for the following items:
@@ Line 105: / Line 109: @@
 * product or component names (capitalize first letters instead of using formatting)
 * paragraph titles (use '''Bold''' instead)
-* example code and file names (use <code>TextRaw</code> instead)
+* example code and file names (use <span><font face="monospace">TextRaw</font></span> instead)
 Use Italics (at least) for the following items:
@@ Line 115: / Line 119: @@
 == Highlighting example code ==
-Use <code>TextRaw</code> or <code>Verbatim</code> to highlight command line examples and function or file names in base text. Do NOT use ''Italics'' for these. The difference between these two is that <code>TextRaw</code> allows normal LaTeX commands inside text will be ignored and handled as plain text.
+Use <span><font face="monospace">TextRaw</font></span> or <code>Verbatim</code> to highlight command line examples and function or file names in base text. Do NOT use ''Italics'' for these. The difference between these two is that <span><font face="monospace">TextRaw</font></span> allows normal LaTeX commands inside text will be ignored and handled as plain text.
-Use <code>TextRaw</code> or <code>Verbatim</code> to highlight the following items:
+Use <span><font face="monospace">TextRaw</font></span> or <code>Verbatim</code> to highlight the following items:
 * paths and file names
@@ Line 126: / Line 130: @@
 * domain names and IP addresses
-Use <code>TextRaw</code> for source code examples. Names need to be written exactly as in source code, for example, <code>ThumbButton</code>, <code>SmallFont</code>, <code>PANGO_SCALE_SMALL</code>, and <code>ButtonTextColor</code>.
+Use <span><font face="monospace">TextRaw</font></span> for source code examples. Names need to be written exactly as in source code, for example, <span><font face="monospace">ThumbButton</font></span>, <span><font face="monospace">SmallFont</font></span>, <span><font face="monospace">PANGO_SCALE_SMALL</font></span>, and <span><font face="monospace">ButtonTextColor</font></span>.
-Use <code>TextRaw</code> for command line examples and file names, for example, <code>sources.list</code>, <code>/opt/bin/share</code>, and <code>apt-get install maemo-python-env</code>.
+Use <span><font face="monospace">TextRaw</font></span> for command line examples and file names, for example, <span><font face="monospace">sources.list</font></span>, <span><font face="monospace">/opt/bin/share</font></span>, and <span><font face="monospace">apt-get install maemo-python-env</font></span>.
 Use references to the source code names in the following way:
-* For user to be able to cancel operation without saving modified data you need to add <code>ThumbButton</code> for your dialog.
+* For user to be able to cancel operation without saving modified data you need to add <span><font face="monospace">ThumbButton</font></span> for your dialog.
 For more information, see chapters [[#Highlighting important text]], [[#Code listings]], and [[#Command line and screen output examples]].
@@ Line 138: / Line 142: @@
 == Highlighting UI element names ==
-Use '''Bold''' font to highlight user interface component caption names in text. For example, if you need to refer to a UI button with the caption '''Cancel''' use the caption '''Cancel''' as the element name and use '''Bold''' to highlight the name. Do NOT use ''Italics'', <code>TextRaw</code> or <code>Verbatim</code> for highlighting UI element names.
+Use '''Bold''' font to highlight user interface component caption names in text. For example, if you need to refer to a UI button with the caption '''Cancel''' use the caption '''Cancel''' as the element name and use '''Bold''' to highlight the name. Do NOT use ''Italics'', <span><font face="monospace">TextRaw</font></span> or <code>Verbatim</code> for highlighting UI element names.
-Use <code>TextRaw</code> or <code>Verbatim</code> only for referring to source code name of the UI element.
+Use <span><font face="monospace">TextRaw</font></span> or <code>Verbatim</code> only for referring to source code name of the UI element.
 Use references to the UI element names in the following way:
@@ Line 150: / Line 154: @@
 == Creating notes ==
-Notes are used in documentation to make the reader pay attention to important issues that have to be taken into consideration. Do not add a note as a part of the body text. Instead, create each note on a separate row using <code>NoteBox</code>:
+Notes are used in documentation to make the reader pay attention to important issues that have to be taken into consideration. Do not add a note as a part of the body text. Instead, create each note on a separate row using NoteBox:
-{{ambox|text=This is an example of a note.}}
+{|
+|-
+| [[Image:dialog-information.png]]
+| '''Note:'''  This is an example of a note.
+|}
-Before using a <code>NoteBox</code> consider whether using ''Italics'' is enough to highlight the issue in the base text. Use <code>NoteBox</code> only for very important issues and avoid ending a section with it.
+Before using a NoteBox consider whether using ''Italics'' is enough to highlight the issue in the base text. Use NoteBox only for very important issues and avoid ending a section with it.
 == Creating cross-references and links ==
@@ Line 275: / Line 283: @@
 == Shortkeys ==
-Use <span><font face="monospace">CTRL+C</font></span> to refer to pressing the control and c keys together. Use the same <code>TextRaw</code> text formatting for all Shortkeys in base text as for command line examples inside text.
+Use <span><font face="monospace">CTRL+C</font></span> to refer to pressing the control and c keys together. Use the same <span><font face="monospace">TextRaw</font></span> text formatting for all Shortkeys in base text as for command line examples inside text.
 == Abbreviations ==
@@ Line 309: / Line 317: @@
 * If the example code used is longer than 50 lines it is recommended (but not required) to include also copyright and licensing information in the beginning of the example code.
-{{ambox|text=Each code example in a Garage project copyrighted by Nokia must use MIT-style licence to allow the free use of the example code.}}
+{|
+|-
+| [[Image:dialog-information.png]]
+| '''Note:'''  Each code example in a Garage project copyrighted by Nokia must use MIT-style licence to allow the free use of the example code.
+|}
 Source code example types supported for listings are C/C++, CSS, HTML, Java, JavaScript, Latex, Pascal, Perl, PHP, Postscript, Python, Ruby, SQL, Tcl, Properties files, Makefile, XML, Log files, Ini files, Shell scripts and more.
@@ Line 358: / Line 370: @@
 Separate command line and screen output examples that are not part of base text and are not source code examples must fulfill the following requirements:
-* Example needs to be inside a <code>GrayBox</code> that separates it from the base text.
+* Example needs to be inside a GrayBox that separates it from the base text.
 * Example box does NOT have a title and CANNOT be referenced.
 * Example does NOT get automatic source highlighting.
 * Example box should be connectied to the surrounding base text.
-The following is an example of how a command line example within a <code>GrayBox</code> can be connected to the surrounding text (notice that an empty line must be given before <code>GrayBox</code>).
+The following is an example of how a command line example within a GrayBox can be connected to the surrounding text (notice that an empty line must be given before GrayBox).
 Following commands show how to...
@@ Line 372: / Line 384: @@
 Commands given above can be used also in...
-Avoid ending a section with a <code>GrayBox</code>.
+Avoid ending a section with a GrayBox.
 == Product names ==
@@ Line 381: / Line 393: @@
 * Chinook
 * Debian
-* [[Open development/Maemo roadmap/Diablo|Diablo]]
+* Diablo
-* [[Open development/Maemo roadmap/Fremantle|Fremantle]]
+* Fremantle
 * Gregale
-* [[Open development/Maemo roadmap/Harmattan|Harmattan]]
+* Harmattan
 * Maemo
 * maemo.org
@@ Line 400: / Line 412: @@
 * MaemoPad
 * Mistral
-* [[Nokia N800|N800]]
+* N800
-* [[Nokia N810|N810]]
+* N810
-* [[Nokia N810WME|N810 WiMAX Edition]]
+* N810 WiMAX Edition
-* [[Nokia N900|N900]]
+* N900
-* [[Nokia 770]]
+* Nokia 770
 * Scirocco
 * Scratchbox