Typographical Guidelines/fr

D'autres pages expliquent la Mise en page et la syntaxe avec des exemples de code.

Important

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.

Astuce

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'[email protected] 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 représentant des données d'entrée sera sur un fond jaune pale, le texte représentant des données de sortie 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/fr|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/fr|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

Remarque

Notez l'utilisation de 1=<nowiki> du texte </nowiki>. Parfois, des parties d'affichage peuvent déranger l'analyseur wiki. Le bloc <nowiki>...</nowiki> vous protège contre cet effet. Également si quelque chose comme n= apparaît dans le corps du texte, l'analyseur du modèle peut être perturbé. Le 1= initial protège contre cet effet. Sinon ce marquage n'a pas d'effet. En résumé : il ne peut pas faire de mal, et il protège contre l'éventualité de dommages collatéraux.

• 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. Une zone de saisie comme celle-là

  {{Input/fr|<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 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.

• Les noms de fichiers et les chemins doivent utiliser le modèle de chemin Path (voir ci-dessous).

Attention

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

Remarque

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 balises <blockquote> et </blockquote> doivent être utilisées 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 page de la Boîte à Outils.

Garder les contenus ensemble

Après que votre texte ait été écrit, une balise est automatiquement ajoutée par le système de traduction. Cela signifie que chaque fois qu'il rencontre une ligne vide, il démarre une nouvelle unité. quand votre texte est présenté aux traducteurs, ils examinent habituellement une unité à la fois, aussi il est important de ne pas laisser de ligne vide au milieu d'un contenu qui doit être traité comme un tout. Normalement un paragraphe entier doit être conservé dans une unité simple ; et jamais une phrase ne doit continuer dans l'unité qui suit !

Si vous avez besoin d'un saut de ligne au milieu d'une section, la meilleure manière d'y parvenir sans créer d'autres unités est d'utiliser <br /> à la fin de la ligne où vous souhaitez placer un saut (pas une nouvelle ligne). Si un espace est nécessaire entre les lignes ajoutez <br /><br />.

Parenthèses non-appairées

Le système de traduction marque une unité traduite comme non traduite si elle contient n'importe quelle sorte de parenthèses non-équilibrées. Si vous avez besoin d'avoir des parenthèses non-équilibrées dans votre texte, veuillez ajouter une parenthèse d'équilibre dans une balise de commentaire, comme ceci :

<!-- }} -->{{ Une ligne 

Une autre ligne}}<!-- {{ -->

Cela vaut pour toutes sortes de parenthèses, même pour les parenthèses ordinaires (bien entendu, il est préférable d'éviter les lignes vides à l'intérieur d'une d'unité déja balisée - voir Garder les contenus ensembles) .

Balises spéciales

Raccourcis clavier et sélection de menu

• <keycap> et </keycap> montre les noms principaux des touches (du clavier) comme Entrée
• <keycap></keycap> peut être utilisé avec un groupe de touches en parallèle, comme Ctrl + Alt + F1 pour lancer un terminal virtuel. (Notez que "(space)+(space)" est utilisé pour ier les touches devant être pressées en parallèle).
• Les séquences de choix de menu doivent être utilisées ainsi <menuchoice> et </menuchoice> par exemple Vue -> Liste des messages -> Agrégation -> Liste de courrier standard
• En général, si l'utilisateur a besoin de choisir un élément, même s'il n'est pas dans un menu, la balise <menuchoice></menuchoiсe> doit être utilisée.
• 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 <menuchoice> but use → in stead of ->, you write & rarr; (without a space between '&' and r!) as in <menuchoice> View</menuchoice> & rarr; <menuchoice>Message List</menuchoice> which yields View → Message List. (Note, that the → character has to be outside of the menuchoice tags to be shown properly

Chemin de fichier et fichiers

Traditionnellement, on a écrit les noms des fichiers et des chemins en utilisant les balises <tt>...</tt> .

<tt>~/.kde/share</tt>

donne

~/.kde/share

Il existe désomais un modèle pour faire cela, qui doit être utilisé pour le nouveau contenu des pages ordinaires de UserBase (mais non pas pour les pages des manuels, par pitié !):

{{Path | ~/.kde/share }}

génère :

 ~/.kde/share 

Le pipe '|' problématique

Dans certaines situations le symbole pipe ne peut pas être utilisé - par exemple quand on ajoute des paramètres à un modèle. Dans de tels cas, veuillez utiliser {{!}} qui s'affichera comme un symbole pipe. Par exemple, si vous voulez afficher une ligne de commande contenant le caractère pipe en utilisant le modèle {{Input/fr|...}}, la manière la plus simple de le faire est celle-ci : {{Input/fr|1=cmd1 {{!}} cmd2}} qui affiche :

cmd1 | cmd2

Si vous écrivez juste {{Input/fr|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é.

Dans beaucoup de cas, vous pouvez aussi entourer le texte contenant le caractère pipe entre des balises <nowiki>... </nowiki>, comme ceci {{Input/fr|1=<nowiki>cmd1 | cmd2</nowiki>}}, ce qui affichera également

cmd1 | cmd2

Contenu traduisible

Tout ce qui est traduisible est contenu entre les balises <translate> et </translate> . Dans beaucoup de cas, des images peuvent être contenues dans la partie traduisible, car il est parfois nécessaire d'utiliser des versions localisées des images pour expliquer un point. La règle de précaution est "En cas de doute, incluez-les ! " .