Link Search Menu Expand Document


Style guidelines and principles

This document provides generic style guidelines for Sailfish OS. The target audience for this documentation is everyone translating Sailfish OS-related material. The goal is to create contemporary translations that provide a high-quality user experience.

Sailfish OS audience and target group for the translations is young, active users accustomed to social media and therefore its language.

Basics of good writing style

  • Write in a personal style, engaging and involving the user.
  • Use active style and present tense. Use imperatives and talk to the user.
  • Make sure the text is consistent and clear and correct in grammar and spelling.
  • Write in short sentences.
  • Use a positive tone, avoid negative expressions.
  • Avoid ambiguity. Make sure that pronouns point clearly to the relevant nouns, and avoid long strings of modifiers or nouns.

Remember we are sailing on a jolly boat. Have fun! Play with the language. Be innovative and guide the readers onto a journey. Do not attempt to use humor, but use fresh and fun tone where it naturally fits. Remember that the most important part is delivering a clear message.

Note that in technical writing, descriptions and instructions should not include text that is written from a marketing point of view.

Language and culture

Because our communication is targeted to international use and part of it will be translated, try to keep the language culturally unambiguous, be careful of religious references, and avoid using idiomatic expressions or slang. The key aspects are clarity and simplicity. Consider these targets when adapting the jolly tone to the texts. In software UI translations: Respect the source text, but do not create word for word translations. Take the context into account when translating.



When possible, leave out articles.

For example:

  • Correct: Ouvrir fichier
  • Incorrect: Ouvrir un/le fichier.


Please try to be informal if that feels natural in your language. Avoid mentioning pronouns.

Keep addressing consistent: e.g. if a paragraph was started using the second person, retain it throughout all its sentences (as opposed to switching to third person or neutral mood).


Use gender-neutral or all-inclusive terms to refer to human beings, rather than terms that include man, woman, and similar masculine and feminine terms.

For example:

  • Correct: utilisateur
  • Incorrect: utilisatrice.


The future tense versus the present tense

English future can be translated as future or present. The use of the future tense will imply a logical consequence of something previously mentioned. The use of the present will create a more direct style. For example:

  • Media player will allow you to select songs: Le lecteur multimédia vous permet de sélectionner des morceaux

Use of imperative

The instructions and commands addressed to the user should be translated in the imperative. For example: For example:

  • Use this area to select options that must be activated: Utilisez cette zone pour sélectionner les options à activer

The literal translation of “could”, “should”, “may” and “might” using the French conditional should be avoided. These forms should be replaced by the present tense. For example:

  • Determine which file should be installed on your system: Indiquez le fichier à installer sur le système


Whenever possible, use the active voice. Keep the message clear and the sentences short.

For example:

  • When Account Settings are created in …: Lorsque vous créez des paramètres de compte dans …


Capitalise application names and company names.

In the UI, start the first word with a capital letter.

Respect capitalisation rules of the language in question.

User Interface menu items are named using verbs.

Empty states in the UI

User Interface empty states are typically written in the 2-sentence form, using verbs and active tone and, where possible, guiding the user towards the next possible steps to take. Keep sentences short and content informative. Where possible, guide user to reflect the good sides of an application or service (like referring to friends instead of contacts in the People app). For example:
(tell the situation, what items are missing) (point user to next actions)
No contacts yet. Pull down to add your friends.

App covers (that are shown in the Home) for empty states aim to be short informative messages. Length is typically two words.


End punctuation

In UI strings, do not use a full stop at the end of a sentence if there’s only one sentence. If there are two or more sentences, use full stops normally.

If the segment ends with the colon or ellipsis, the translation should follow the source.

Use of punctuation signs

In French, commas and periods follow immediately the character preceding them. Colons and semicolons require a non-breaking space before them.

According to the English language standards, you insert two spaces after a period. In French, there should only be one space.

Comma: In the enumerations separated by commas, the last element is normally preceded by a conjunction. Do not use a comma before this conjunction.

Colon: After a colon, lower case is generally used, except where the sentence is a quote, a proper name, or where more than one sentence follow the colon.


In technical writing, use common abbreviations. Do not use Latin abbreviations.

In the UI, use common abbreviations, including Latin abbreviations. Make sure text clarity does not suffer. If in doubt, do not use an abbreviation.

Do not use a full stop in or after acronyms or initialisms, e.g.:

  • Correct: WLAN
  • Incorrect: W.L.A.N.

Do not use a full stop with unit (measurement) symbols, e.g.:

  • Correct: kg
  • Incorrect: kg.

Use a full stop with Latin abbreviations, e.g.:

  • Correct: e.g., ca., etc.
  • Incorrect: eg, ca, etc

In the case of the days of the week and the name of months, use the common French abbreviations. Words abbreviated should include the initial consonant of the syllable next to the one where the word is split. For example, abbreviate Envoyer in the form of Env. instead of Envo.


An acronym is an association of initials, each initial representing a word. Write acronyms in capital letters, without period or space between them.

When an acronym is translated because of industry usage, it should appear with the following format : translated expansion followed by substituted acronym. If this acronym reappears in the text, the translated expansion will not be necessary. For example:

  • Federal Communications Commission (FCC): Commission fédérale des communications (FCC, Federal Communications Commission)


The correct French accented characters must be used. When characters with accents are capital letters, they require the accent. For example:

  • À l’aide de la zone de liste, sélectionnez l’option souhaitée.g


In UI texts, if it is necessary to hyphenate a word in order to make the text fit in the layout, do not add an ordinary hyphen. Use a soft hyphen instead. Do not hyphenate if not necessary.

When a hyphenated word has to be split because of a line break, make sure the hyphen remains with the first half of the word.

Never split product names and trademarks. Measurement units and sizes should not be split either.


Do not create plurals with parentheses. Consult translation tool user guide for handling the plurals.

Quotation marks

Respect language’s quotation rules. A comprehensive list of marks can be found here:

English quotes must be replaced with the French chevrons (« and »). Note that a non-breaking space must be inserted after the opening chevron («) and before the closing chevron (»).


Several rules of thumb about commas don’t correspond to an actual grammar rule. In general, please do apply the rule of not using a comma before “e”, but do use one if it helps to create the right logical connection between different parts of a sentence. The most frequent case is if the sentence beginning with “e” is preceded by a parenthetical sentence enclosed in commas.


Use a comma to separate elements in a series. For example:

  • Create, modify, and delete options: Créez, modifiez et supprimez des options

Use a semicolon to separate items in a series when one or more items have internal punctuation.

Do not use a comma before « et » in a listing. See example above.


In technical writing, write lists with bullets.

In the UI, write lists without bullets or colons.

Use a consistent punctuation in bullet lists. If the bulleted items represent complete sentences, each should begin with a capital letter and ends with a period. E.g.:

Pour plus d´informations, reportez-vous aux chapitres suivants.

  • Le chapitre 2 présente les traités de navigation.
  • Le chapitre 3 présente les règles de navigation internationales.

If the bulleted items continue an introductory clause, each should begin with a lower case letter and ends with a semicolon, but the last sentence, which should end with a period:

Les options suivantes sont disponibles :

  • passer entre les bouées de signalisation ;
  • contourner la bouée par babord ;
  • contourner la bouée par tribord.

Items in a list that are not whole sentences or continuations of sentences should begin with capitals but have no ending period:

Configuration système nécessaire :

  • Windows XP ou 7 ou version ultérieure
  • 1 Go de RAM
  • 256 Mo d’espace disque disponible


In technical writing, create structured, consistent and accurate headings. Consider verb structures in headings.

Text modules

In technical writing, make sure each module can be read independently, containing all the needed information so that modules do not need to be read in any certain order.


In technical writing, when describing procedures, make sure to describe the steps clearly with only one task per step. Describe the expected results of those steps.



Write numbers as digits, including numbers below 10.

For example:

  • Correct: 11 messages reçus
  • Incorrect: onze messages reçus


English measurements should be converted into French. The measurement equivalent in French will be followed. Imperial system measurements must be converted into Metric System measurements. Use numerals for measurements.

Use a non breaking space between the numeral and the unit, including degree and percentage sign. Their abbreviations should not be followed by a full stop.


Sailfish OS has a separate Terminology project to maintain consistency. Use that approved terminology when available.

Company names

Do not translate company names unless there is an official, translated name available.

Product names and trademarks

Do not translate product names or trademarks.

Warnings, cautions, and notes are legal texts that need to be confirmed with legal department. In case of legal texts, follow the instructions carefully and ask for more information if needed.


When finalising translations for the UI, check the following:

  • Everything has been translated to your best knowledge.
  • Spell check is done.
  • Check consistency with the other translations done for the language.
  • Ensure correct Sailfish OS terminology is used. If needed, propose new term entries.
  • Confirm legal texts are consistent with the source.
  • Company and product names, trademarks, symbols, and measurements have not been hyphenated.
  • Ensure regional formats are retained, such as date, time, numeric and quotation literals.

When finalising texts for the technical writing, check these points as well:

  • Titles and headings are structured and accurate.
  • Language is clear and consistent.
  • Sentences vary in length and have a clear form.