Typographical Guidelines - KDE UserBase

Typographical Guidelines - KDE UserBase Wiki
Jump to content
From KDE UserBase Wiki
Other languages:
Lëtzebuergesch
català
dansk
italiano
русский
українська
עברית
বাংলা
中文（中国大陆）
There are separate pages explaining
syntax
with example code.
Important
Adhering to these typographic guidelines will ensure that your documentation can be accurately and easily exported for translation purposes. Some guidelines may not be applicable for non-English languages. These should be noted on specific language pages, linked from
Translation Workflow
. If no such page exists for your language, please add one and make guidelines there.
Links
Links to other UserBase pages should follow this pattern:
[[Special:MyLanguage/page name|whatever]]
[[Special:MyLanguage/Welcome to KDE UserBase|start page]] links to the welcome page in the readers language if the translation exists or else to the english version of that page.
Links to external pages follow normal wiki syntax:
[https://web.site.xxx/page text]
Bold Text
Use bold text to highlight
Window titles
Common labels that are not user-configurable
Icon captions
Program names
For example:
Highlighting a selection of text will copy it to
Klipper
Italic Text
Use italic text to emphasise
Words or phrases as in general writing.
Titles when referencing other works.
The first use of an unfamiliar word.
Some examples:
Save your work at this point.
Details can be found in
Samba 3 by Example
....
KDE Manuals are in
Docbook
format.
Tip
Programs
are launched by users,
components
are used by programs
Combined Bold and Italic Text
Use this combination for replaceable or variable text.
Some examples:
To connect to your remote server, type
ssh
[email protected]
in
Konsole
In rpm-based distributions, the command
rpm -q
packagename
will result in
package-version-release
Mono-spaced Text
Code should be presented in mono-spaced text, usually boxed, as shown below. Input text will be on a light yellow background. For output text, the background colour will be a light grey.
Code, whether single lines or blocks, use templates to ensure consistency
Use the Input template like this:
{{Input|1=<nowiki>
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk
rm -r ~/.kde4/share/apps/nepomuk
nepomukserver</nowiki>}}
This will display like this:
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk
rm -r ~/.kde4/share/apps/nepomuk
nepomukserver
Output works the same way:
{{Output|1=terminal output
is also shown as code,
but on a grey background}}
which displays as
terminal output
is also shown as code,
but on a grey background
Note
Note the use of
1= some text
. Occationally, parts of literal displays may confuse the wiki parser. The
...
block protects against that. Also if something like
n=
appears in the literal body, the template parser may get confused. The initial
1=
protects against that. Otherwise this markup has no effect. In short: it can't hurt, and it protects against the possibility of some nasty side effects.
Starting an Input or Output template on a new line will break the display format if it is within lists. Simply continue on the same line if you need to correct this.
You can also combine input/output areas with
GeSHi syntaxhiglighting
. An input area like this
{{Input|<syntaxhighlight lang="php" line>
# Initialise common code
$preIP = dirname( __FILE__ );
require_once( "$preIP/includes/WebStart.php" );
</syntaxhighlight>}}
will result in
'"`UNIQ--syntaxhighlight-00000015-QINU`"'
Single code words can be kept in-line by using
<code></code>
It will
display
like this. Note, that if the tag is immediately preceded by a newline character, it will not display properly. File names and paths should use the Path template (see below). Warning In-line code markup should be short! It looks strange - and ugly - if a string of code words is split between lines. And remember: even if it looks good in your browser, not everyone uses the same screen size! And even if your text looks good on all screen sizes translations may still suffer. It is best to use the Input template for code unless it is really short. Note Please avoid using shell commands or other code words as verbs. This does not translate well. Always treat code words as proper names. Block Quotes The tags

and

 should be used when quoting other works or other pages. This produces a proportional italic font, with some padding.
Here is an example of the display that you get by using the blockquote tags.
Text in Section Headers
Even though the criteria above may be met, do not use Bold text in section headers or in links.
Text in Information, Note, Tip or Warning Templates
Bold text should be avoided in the text within these templates. Italic text for emphasis may still be used - use sparingly for maximum effect.
Lists
You can have various kinds of lists in your pages — bulleted, numbered or itemized. Find details on the
Toolbox
page.
Keeping things together
After your text is written some markup is automatically added by the translation system. This means that whenever it sees a blank line, it starts a new unit. When your text is presented to translators, they typically see it one unit at a time, so it is important not to leave a blank lines in the middle of something that should be treated as a unit. Normally an entire paragraph should be kept in a single unit; and under no circumstance should a sentence be split between units!
If you need a linebreak in the middle of a section, the preferred way to achieve this without breaking units is to use 
 at the end of the line where you want to break to occur (not on a new line). If you need space between the lines add 

.
Unbalanced brackets
The translation system marks any translated unit as incompletely translated if it contains any kind of unbalanced brackets. If you need to have unbalanced brackets in your text, please add a balancing bracket in a comment tag, like this:
<!-- }} -->{{ A line
Another line}}<!-- {{ -->
This goes for all kinds of brackets, even ordinary parentheses. (Of course it is normally better to avoid blank lines within a mark up unit - see
Keeping things together
.)
Special Tags
Key presses and menu selections
 and  denote (keyboard) key names e.g.
Enter
 can also be used around groups of keys to be used concurrently, e.g.
Ctrl + Alt + F1
to launch a virtual terminal. (Note that "(space)+(space)" is used to link keys to be pressed concurrently).
Sequences of menu choices should use  and  for example
View -> Message List -> Aggregation -> Standard Mailing List
In general, if the user needs to choose an element, even if it is not in a menu, the  markup should be used.
If you are contributing to a manual page, you should always use the markup describes above. For other pages, though, there is a template to enter menu selections: {{Menu|Top|sub|...}}. Fx, {{Menu | View | Message List | Aggregation | Standard Mailing List}} yields
View
Message List
Aggregation
Standard Mailing List
If you want to use the  but use → in stead of ->, you write
& rarr;
(without a space between '&' and r!) as in  View & rarr; Message List which yields
View
Message List
. (Note, that the → character has to be outside of the menuchoice tags to be shown properly
Files and file paths
Traditionally, file names and paths have been marked up between ... tags.
<tt>~/.kde/share</tt>
yields
~/.kde/share
There is now also a template for this, which should be preferred in new content for ordinary UserBase pages (but not for manual pages, please!):
{{Path | ~/.kde/share }}
yields
~/.kde/share
The Problematic Pipe
In some situations the pipe symbol can't be used - for instance when adding parameters into a template. In any such case, please use {{!}} which will display as a pipe symbol. For example, if you want to display a command line containing the pipe character using the {{Input|...}} template, the simplest way to do it is this:
{{Input|1=cmd1 {{!}} cmd2}}
which displays
cmd1 | cmd2
If you just write
{{Input|cmd1 | cmd2}}
you get instead
cmd1
the problem being, that
cmd2
is seen as a second parameter to the template, which in this case is not used.
In many cases, you can also enclose the text containing the pipe character between ...  tags, like this
{{Input|1=cmd1 | cmd2}}
, which also displays
cmd1 | cmd2
Translatable Content
Everything that is translatable is contained within  and  tags. In most cases any images should be contained within the translatable section, as it is sometimes necessary to use localised versions of the images to explain a point. The rule of thumb is "If in doubt, include it!".
Retrieved from "
Categories
Pages with syntax highlighting errors
Contributing