Typographical Guidelines: Difference between revisions

From KDE Wiki Sandbox
No edit summary
No edit summary
Line 69: Line 69:


If an list is long it may be felt desirable to split the list, making it easier to read.  If this is done by newline characters it splits the translation sections.  The way to achieve this visually but without that side-effect is to use <nowiki><br /></nowiki> at the end of the line where you want to break to occur (not on a new line).
If an list is long it may be felt desirable to split the list, making it easier to read.  If this is done by newline characters it splits the translation sections.  The way to achieve this visually but without that side-effect is to use <nowiki><br /></nowiki> at the end of the line where you want to break to occur (not on a new line).
==Keeping thing 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 blank lines in the middle of things, that is part of a single unit. Normally an entire paragraphs should be kept in a single unit; and in no circumstance should a sentence be split between units!
If you feel that you need some blank space please use <nowiki><br /></nowiki>, as described in the section on [[Special:myLanguage/Typographical_Guidelines#Lists|Lists]].
==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:<br />
{{Input|1=
<nowiki>{{ A line <!-- }} -->
Another line <!-- {{ --> }}</nowiki>
}}
This goes for all kinds of brackets, even ordinary parentheses.


==Special Tags==
==Special Tags==

Revision as of 05:46, 4 October 2010

There are separate pages explaining Page Layout and syntax with example code.

Adhering to these typographic guidelines will ensure that your documentation can be accurately and easily exported for translation purposes.

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 username@domain.name 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, boxed, as shown below. Input text will be on a pale yellow background. For output text, the background colour will be violet-grey.

  • Code, whether single lines or blocks,use templates to ensure consistency
  • Check Edit to see the code to use the Input template:
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:
terminal output
is also shown as code, but
on a grey background

Text in Section Headers

Even though the criteria above may be met, do not use Bold text in section headers.

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

If an list is long it may be felt desirable to split the list, making it easier to read. If this is done by newline characters it splits the translation sections. The way to achieve this visually but without that side-effect is to use <br /> at the end of the line where you want to break to occur (not on a new line).

Keeping thing 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 blank lines in the middle of things, that is part of a single unit. Normally an entire paragraphs should be kept in a single unit; and in no circumstance should a sentence be split between units!

If you feel that you need some blank space please use <br />, as described in the section on Lists.

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.

Special Tags

  • <keycap> and </keycap> denote (keyboard) key names e.g. Enter
  • <keycap></keycap> can also be used around groups of keys to be used concurrently, e.g. Ctrl+Alt+F1 to launch a virtual terminal. (Note that Note that "+" is used to link keys to be pressed concurrently).
  • Sequences of menu choices should use <menuchoice> and </menuchoice> for example View -> Message List -> Aggregation -> Standard Mailing List

(Note the use of "(space)->(space)" to denote the sequence of clicks.)

Translatable Content

Everything that is translatable is contained within <translate> and </translate> tags. In most cases any images should be contained within the translatable section, as it is sometimes necessary to us localised versions of the images to explain a point. The rule of thumb is "If in doubt, include it!".