Typographical Guidelines/fr

D'autres pages expliquent Mise en page et Boîte à outils avec des exemples de code.

Remember

Adhérer à ces règles typograhiques assurera que votre documentation puisse être exportée précisement et facilement afin d'être traduite. Certaines règles peuvent ne pas être applicables pour d'autres langues. Elles sont donc notées sur des pages spécifiques par langue, voir Processus de Traduction. Si cette page n'existe pas dans votre langue, veuillez l'ajouter et y écrire les règles.

Texte en Gras

Utilisez le gras pour mettre en valeur

• Les titres de fenêtres
• Les textes fixes communs qui ne sont pas modifiables par l'utilisateur
• Les légendes d'icônes
• Les noms de programmes

Par exemple :

• Surligner une sélection de texte le copiera dans Klipper.

Texte en Italique

Utilisez le texte en italique pour mettre en valeur :

• Les mots ou phrases comme en écriture normale.
• Les titres lorsque vous référencez d'autres travaux.
• La première utilisation d'un mot inhabituel.

Quelques exemples :

• Enregistrez votre travail à cet instant.
• Les détails peuvent être trouvés dans Samba 3 par l'Exemple....
• Les manuels de KDE sont au format Docbook.

Tip

Les Programmes sont lancés par les utilisateurs, les composants sont utilisés par les programmes

Texte en Gras et Italique Combiné

Utilisez cette combinaison pour le texte remplaçable ou variable.

Quelques exemples :

• Pour vous connecter à votre serveur distant, saisissez ssh nom-d'utilisateur@domaine.nom dans Konsole.
• Dans les distributions basées sur rpm, la commande rpm -q nom_du_paquet renverra paquet-version-release.

Texte mono-espacé

Le code devrait être présenté sous la forme de texte mono-espacé, en général dans une boîte, comme ci-dessous. Le texte saisi sera sur un fond jaune pale, le texte affiché sera sur un fond gris-violet.

• Le code, que ce soit des lignes simples ou des blocs, utilise des modèles pour assurer son uniformité

* Utilisez le modèle Input comme ceci:

{{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>}}

Il s'affichera comme cela:

qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk
rm -r ~/.kde4/share/apps/nepomuk
nepomukserver

• Output fonctionne de la même manière :

  {{Output|1=<nowiki>l'affichage du terminal est aussi affiché comme du code, mais sur fond gris</nowiki>}}

  qui s'affichera ainsi

  l'affichage du terminal est aussi affiché comme du code, mais sur fond gris

Note

Notez l'utilisation de 1=<nowiki> du texte </nowiki> pour éviter les situations qui rompent le format d'affichage

• Utiliser les modèles Input ou Output sur une nouvelle ligne rompra le format d'affichage à l'intérieur des listes. Continuez simplement sur la même ligne si vous avez besoin de corriger cela.

• Vous pouvez aussi combiner les zones de saisie/et d'affichage avec GeSHi syntaxhiglighting. An input area like this

  {{Input|<syntaxhighlight lang="php" line>
  # Initialisation du code commun
  $preIP = dirname( __FILE__ );
  require_once( "$preIP/includes/WebStart.php" );
  </syntaxhighlight>}}

  affichera

  # Initialisation du code commun
  $preIP = dirname( __FILE__ );
  require_once( "$preIP/includes/WebStart.php" );
  

• Les extraits de code très courts peuvent être conservés dans la ligne en utilisant

  <code></code>

  Le code It will s'affichera comme cela. Notez que si la balise <code> est immédiatement précédée d'un retour à la ligne, elle ne s'affichera pas correctement.

• <tt> </tt>

  est utile pour afficher les noms de fichiers et les chemins, de la manière suivante un/chemin/vers/ici

Warning

Le code en ligne devrait être court ! Cela fait bizarre, et moche, si une ligne de code est séparée en deux lignes. Et rappelez-vous : même si cela à l'air bon dans votre navigateur, tout le monde n'a pas la même taille d'écran. Et même si votre texte à l'air bon sur toutes les tailles d'écran, les traductions peuvent toujours en souffrir. Il est recommandé d'utiliser le modèle Input pour le code à moins que celui-ci ne soit vraiment ourt.

Note

Veuiller éviter d'utiliser les commands shell ou d'autres mots-clefs de programmation comme des verbes. Ils ne se traduisent pas très bien. Traitez toujours les mots-clefs comme des noms propres.

Citations

Les tags <blockquote> et </blockquote> doivent être utilisés lorsque d'autres travaux ou d'autres pages sont cités. Ils produisent une police italique proportionelle, avec un espacement.

Voici un exemple de ce que vous obtenez en utilisant les balises blockquote.

Texte dans les En-têtes de Section

Même si un des critères ci-dessus peut être atteint, n'utilisez pas de texte en gras dans les en-têtes de section ou dans les liens.

Texte dans les Modèles Information, Note, Tip ou Warning

Le texte en gras devrait être évité dans le texte contenu dans ces modèles. Le texte en italique pour mettre en valeur un passage peut toujours être utilisé, mais avec parcimonie afin de maximiser son effet.

Listes

De nombreuses listes sont disponibles pour vos pages — à puces, numérotées ou détaillées. Vous pouvez touver tous les détails sur la Boîte à Outils.

Garder les contenus ensemble

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 is without breaking units is to use <br /> 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 <br /><br />.

Parenthèses non-équilibrées

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.)

Balises spéciales

• <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 "(space)+(space)" 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
• In general, if the user needs to choose an element, even if it is not in a menu, the <menuchoice></menuchoiсe> markup should be used.

le Pipe problématique

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

si vous écrivez juste {{Input|cmd1 | cmd2}} vous obtiendrez à la place

cmd1 

car le problème est que cmd2 est considéré comme un second paramètre pour le modèle, qui dans ce cas n'est pas utilisé.

In many cases, you can also enclose the text containing the pipe character between <nowiki>... </nowiki> tags, like this {{Input|1=<nowiki>cmd1 | cmd2</nowiki>}}, which also displays

cmd1 | cmd2

Contenu traduisible

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 use localised versions of the images to explain a point. The rule of thumb is "If in doubt, include it!".