1 files changed, 390 insertions, 0 deletions
diff --git a/markup/pod/live-manual/media/text/fr/appendix_style-guide.ssi b/markup/pod/live-manual/media/text/fr/appendix_style-guide.ssi
new file mode 100644
index 0000000..7217a77
--- /dev/null
+++ b/markup/pod/live-manual/media/text/fr/appendix_style-guide.ssi
@@ -0,0 +1,390 @@
+:B~ Guide de style
+
+1~style-guide Guide de style
+
+2~ Lignes directrices pour les auteurs
+
+Cette section traite des considérations générales à prendre en compte lors
+de la rédaction de la documentation technique pour live-manual. Elles sont
+divisées en caractéristiques linguistiques et en procédures recommandées.
+
+*{Remarque:}* Les auteurs doivent lire d'abord {Contribuer à ce document}#how-to-contribute
+
+3~ Caractéristiques linguistiques
+
+_* /{Utilisez un anglais simple}/
+
+Gardez à l'esprit qu'un pourcentage élevé de vos lecteurs ne sont pas de
+langue maternelle anglaise. Donc, en règle générale, essayez d'utiliser des
+phrases significatives courtes, suivies d'un point.
+
+Cela ne signifie pas que vous devez utiliser un style naïf et simpliste. Il
+s'agit d'une suggestion pour essayer d'éviter, autant que possible, phrases
+subordonnées complexes qui rendent le texte difficile à comprendre pour les
+locuteurs non natifs de l'anglais.
+
+_* /{Variété de l'anglais}/
+
+Les variétés les plus répandues de l'anglais sont la britannique et
+l'américain, donc il est très probable que la plupart des auteurs utilisent
+l'un ou l'autre. Dans un environnement collaboratif, la variété idéale
+serait «l'anglais international», mais il est très difficile, pour ne pas
+dire impossible, de se prononcer sur quelle variété parmi toutes celles qui
+existent déjà, est la meilleure à utiliser.
+
+Nous croyons que les différentes variétés peuvent se mélanger sans créer
+incompréhensions, mais en termes généraux, vous devriez essayer d'être
+cohérent et avant de décider entre britannique, américain ou toute autre
+variété anglaise à votre discrétion, s'il vous plaît jeter un oeil à la
+façon dont d'autres gens écrivent et essayer de les imiter.
+
+_* /{Soyez équilibré}/
+
+Ne soyez pas partial. Évitez d'inclure des références à des idéologies
+totalement étrangères à live-manual. L'écriture technique doit être aussi
+neutre que possible. Il est dans la nature même de l'écriture scientifique.
+
+_* /{Soyez politiquement correct}/
+
+Essayez d'éviter un langage sexiste autant que possible. Si vous avez besoin
+de faire référence à la troisième personne du singulier, de préférence
+utilisez «they» plutôt que «he» ou «she» ou inventions maladroites telles
+que «s/he», «s(he)», etc.
+
+_* /{Soyez concis}/
+
+Allez droit au but et ne pas errer sans but. Donner autant d'informations
+que nécessaire, mais ne donnez pas plus d'informations que nécessaire,
+c'est-à-dire, ne pas expliquer les détails inutiles. Vos lecteurs sont
+intelligents. Présumez une certaine connaissance préalable de leur part.
+
+_* /{Minimiser le travail de traduction}/
+
+Gardez à l'esprit que ce que vous écrivez devra être traduit dans plusieurs
+autres langues. Cela implique qu'un certain nombre de gens devront faire un
+travail supplémentaire si vous ajoutez des informations inutiles ou
+redondantes.
+
+_* /{Soyez cohérent}/
+
+Comme suggéré précédemment, il est presque impossible de normaliser un
+document collaboratif dans un ensemble parfaitement unifié. Cependant, tous
+les efforts de votre côté pour écrire d'une manière cohérente avec le reste
+des auteurs seront appréciés.
+
+_* /{Soyez cohésive}/
+
+Utilisez autant de dispositifs de formation de texte que nécessaire pour
+rendre votre texte cohésive et sans ambiguïtés. (Les dispositifs de
+formation de texte sont des marqueurs linguistiques tels que les
+connecteurs).
+
+_* /{Soyez descriptif}/
+
+Il est préférable de décrire le point en une ou plusieurs paragraphes que
+simplement en utilisant un certain nombre de phrases dans un style typique
+"changelog". Décrivez-le! Vos lecteurs apprécieront ça.
+
+_* /{Dictionnaire}/
+
+Cherchez le sens des mots dans un dictionnaire ou une encyclopédie si vous
+ne savez pas comment exprimer certaines notions en anglais. Mais gardez à
+l'esprit qu'un dictionnaire peut être votre meilleur ami ou peut se
+transformer en votre pire ennemi si vous ne savez pas comment l'utiliser
+correctement.
+
+L'anglais possède le plus grand vocabulaire qui existe (avec plus d'un
+million de mots). Beaucoup de ces mots sont des emprunts d'autres
+langues. Lorsque l'on regarde le sens des mots dans un dictionnaire
+bilingue, la tendance d'un locuteur non natif de l'anglais est de choisir
+celui qui sonne plus similaire dans leur langue maternelle. Cela se
+transforme souvent en un discours excessivement formelle qui ne semble pas
+tout à fait naturel en anglais.
+
+En règle générale, si un concept peut être exprimé en utilisant différents
+synonymes, c'est un bon conseil choisir le premier mot proposé par le
+dictionnaire. En cas de doute, le choix des mots d'origine germanique
+(Habituellement mots monosyllabiques) est souvent la bonne chose à faire. Il
+faut savoir que ces deux techniques peuvent produire un discours plutôt
+informel, mais au moins votre choix des mots sera d'utilisation grand et
+généralement accepté.
+
+L'utilisation d'un dictionnaire de collocations est recommandé. Ils sont
+extrêmement utiles quand il s'agit de savoir quels mots surviennent
+généralement ensemble.
+
+Encore une fois, c'est une bonne pratique apprendre à partir du travail des
+autres. Grâce à un moteur de recherche pour vérifier comment les autres
+auteurs utilisent certaines expressions peut aider beaucoup.
+
+_* /{Faux amis, expressions idiomatiques et autres expressions}/
+
+Attention aux faux amis. Peu importe comment vous êtes compétent dans une
+langue étrangère, vous ne pouvez pas vous empêcher de tomber de temps en
+temps dans le piège de ce qu'on appelle les «faux amis», des mots qui se
+ressemblent dans les deux langues, mais dont les significations ou les
+utilisations pourrait être complètement différent.
+
+Essayez d'éviter les expressions idiomatiques autant que possible. Les
+expressions idiomatiques sont des expressions qui peuvent transmettre un
+sens complètement différent de ce que leurs mots individuels semblent
+signifier. Parfois, les expressions idiomatiques peuvent être difficiles à
+comprendre, même pour les locuteurs natifs de l'anglais!
+
+_* /{Évitez l'argot, les abréviations, les contractions...}/
+
+Même si vous êtes encouragés à utiliser un langage simple, l'anglais de tous
+les jours, la rédaction technique appartient au registre formel de la
+langue.
+
+Essayez d'éviter l'argot, abréviations inhabituels qui sont difficiles à
+comprendre et surtout les contractions qui tentent d'imiter le langage
+parlé. Sans oublier typique expressions d'irc et favorables à la famille.
+
+3~ Procédures
+
+_* /{Tester avant d'écrire}/
+
+Il est important que les auteurs testent leurs exemples avant de les ajouter
+à live-manual pour s'assurer que tout fonctionne comme décrit. Tester sur
+un chroot propre ou une machine virtuelle peut être un bon point de
+départ. Par ailleurs, il serait idéal si les tests ont ensuite été effectués
+sur des machines différentes avec un matériel différent pour repérer
+d'éventuels problèmes qui pourraient survenir.
+
+_* /{Exemples}/
+
+En fournissant un exemple essayer d'être aussi précis que possible. Un
+exemple est, après tout, juste un exemple.
+
+Il est souvent préférable d'utiliser une ligne qui ne s'applique qu'à un cas
+particulier que l'utilisation d'abstractions qui peuvent confondre vos
+lecteurs. Dans ce cas, vous pouvez fournir une brève explication des effets
+de l'exemple proposé.
+
+Il peut y avoir des exceptions lorsque l'exemple suggère d'utiliser
+certaines commandes potentiellement dangereuses qui, si elles sont mal
+utilisées, peuvent causer des pertes de données ou d'autres effets
+indésirables similaires. Dans ce cas, vous devez fournir une explication
+approfondie des effets secondaires possibles.
+
+_* /{Liens externes}/
+
+Les liens externes ne doivent être utilisés lorsque l'information sur ces
+sites est cruciale quand il s'agit de comprendre un point particulier. Même
+si, essayez d'utiliser des liens externes aussi peu que possible. Les liens
+internet sont susceptibles de changer de temps en temps résultant en des
+liens brisés et en laissant vos arguments dans un état incomplet.
+
+D'ailleurs, les gens qui lisent le manuel hors ligne n'auront pas la chance
+de suivre ces liens.
+
+_* /{Évitez les marques et les choses qui violent la licence sous laquelle
+le manuel est publié}/
+
+Essayez d'éviter les marques autant que possible. Gardez à l'esprit que
+d'autres projets peuvent utiliser la documentation que vous écrivez. Donc,
+vous compliquez les choses pour eux si vous ajoutez certaines matières
+spécifiques.
+
+live-manual est sous la licence GNU GPL. Cela a un certain nombre de
+conséquences qui s'appliquent à la distribution de la matière (de toute
+nature, y compris les graphiques ou logos protégées) qui est publiée avec le
+manuel.
+
+_* /{Ecrire un premier projet, réviser, modifier, améliorer, refaire si
+nécessaire}/
+
+ - Remue-méninges!. Vous devez organiser vos idées d'abord dans une séquence
+   logique des événements.
+
+ - Une fois que vous avez en quelque sorte organisé ces idées dans votre
+   esprit écrire un premier projet.
+
+ - Réviser la grammaire, la syntaxe et l'orthographe. Gardez à l'esprit que
+   les noms propres des versions, tels que ${testing} ou sid, ne doivent pas
+   être capitalisés lorsqu'ils sont utilisés comme noms de code. Pour
+   vérifier l'orthographe, on peut exécuter la cible "spell". C'est à dire,
+   #{make spell}#
+
+ - Améliorer vos phrases et refaire n'importe quelle partie si nécessaire.
+
+_* /{Chapitres}/
+
+Utilisez le système de numérotation classique des chapitres et
+sous-titres. Par exemple 1, 1.1, 1.1.1, 1.1.2 ... 1.2, 1.2.1, 1.2.2 ... 2,
+2.1 ... et cetera. Voir marqueurs ci-dessous.
+
+Si vous avez d'énumérer une série d'étapes ou phases dans votre description,
+vous pouvez également utiliser des nombres ordinaux: premier, deuxième,
+troisième ... ou d'abord, puis, après cela, enfin ... Sinon, vous pouvez
+utiliser les éléments à puces.
+
+_* /{Balisage}/
+
+Et finalement, live-manual utilise {SiSU}http://www.sisudoc.org/ pour
+traiter les fichiers texte et pour produire plusieurs formats. Il est
+recommandé de consulter le {manuel
+SiSU}http://www.sisudoc.org/sisu/en/html/sisu_manual/markup.html pour se
+familiariser avec son balisage, ou bien tapez:
+
+code{
+
+ $ sisu --help markup
+
+}code
+
+Voici quelques exemples de balisage qui peuvent éventuellement vous aider:
+
+ - Pour accent/texte en gras:
+
+code{
+
+*{foo}* or !{foo}!
+
+}code
+
+il produit: *{foo}* or !{foo}!. Utiliser pour mettre l'accent sur certains
+mots-clés.
+
+ - Pour italique:
+
+code{
+
+/{foo}/
+
+}code
+
+il produit: /{foo}/. Utiliser par exemple, pour les noms des paquets Debian.
+
+ - Pour monospace:
+
+code{
+
+#{foo}#
+
+}code
+
+il produit: #{foo}#. Utiliser par exemple, pour les noms des commandes. Et
+aussi pour souligner certains mots clés ou des choses comme les chemins.
+
+ - Pour les blocs de code:
+
+code{
+
+ code{
+
+  $ foo
+  # bar
+
+ }code
+
+}code
+
+il produit:
+
+code{
+
+ $ foo
+ # bar
+
+}code
+
+Utilisez #{code{}# pour ouvrir et #{}code}# pour fermer les balises. Il est
+important de se rappeler de laisser un espace au début de chaque ligne de
+code.
+
+2~guidelines-translators Lignes directrices pour les traducteurs
+
+Cette section traite des considérations générales à prendre en compte lors
+de la traduction du contenu du live-manual.
+
+Comme recommandation générale, les traducteurs doivent avoir lu et compris
+les règles de traduction qui s'appliquent à leurs langues
+spécifiques. Habituellement, les groupes de traduction et listes de
+diffusion fournissent des informations sur la façon de produire un travail
+de traduction qui respecte les normes de qualité de Debian.
+
+*{Remarque:}* Les traducteurs doivent aussi lire {Contribuer à ce document}#how-to-contribute. En particulier, la section {Traduction}#translation
+
+3~ Conseils de traduction
+
+_* /{Commentaires}/
+
+Le rôle du traducteur est de transmettre le plus fidèlement possible le sens
+des mots, des phrases, des paragraphes et des textes comme écrit par les
+auteurs originaux dans leur langue cible.
+
+Donc, ils devraient s'abstenir d'ajouter des commentaires personnels ou des
+morceaux d'informations supplémentaires de leur propre chef. S'ils veulent
+ajouter un commentaire pour d'autres traducteurs travaillant sur les mêmes
+documents, ils peuvent le laisser dans l'espace réservé pour cela. Autrement
+dit, l'en-tête des chaînes dans les fichiers *{po}* précédés d'un signe
+*{#}*. Nombreuses logiciels de traduction graphiques peuvent gérer
+automatiquement ces types de commentaires.
+
+_* /{NDT, Note Du Traducteur}/
+
+Il est parfaitement acceptable cependant, inclure un mot ou une expression
+entre parenthèses dans le texte traduit si, et seulement si, cela fait le
+sens d'un mot ou d'une expression difficile plus clair pour le lecteur. A
+l'intérieur des parenthèses, le traducteur doit mettre en évidence que
+l'addition a été leur en utilisant l'abréviation "NDT" ou "Note Du
+Traducteur ". 
+
+_* /{Phrases impersonnelles}/
+
+Les documents écrits en anglais font une utilisation intensive de la forme
+impersonnelle "you". Dans d'autres langues qui ne partagent pas cette
+caractéristique, ce pourrait donner la fausse impression que les textes
+originaux traitent directement le lecteur quand en réalité ils ne le font
+pas. Les traducteurs doivent être conscients de ce fait et traduir dans leur
+langue le plus fidèlement que possible.
+
+_* /{Faux amis}/
+
+Le piège des "faux amis" expliqué avant s'applique surtout aux
+traducteurs. Vérifiez le sens des faux amis suspectes en cas de doute.
+
+_* /{Balisage}/
+
+Les traducteurs qui travaillent d'abord avec les fichiers *{pot}* et plus
+tard avec les fichiers *{po}* trouveront de nombreuses caractéristiques de
+balisage dans les chaînes. Ils peuvent traduire le texte de toute façon,
+tant qu'il est traduisible, mais il est extrêmement important qu'ils
+utilisent exactement le même balisage que la version originale anglaise.
+
+_* /{Blocs de code}/
+
+Même si les blocs de code sont généralement intraduisibles, les inclure dans
+la traduction est la seule façon d'obtenir une traduction complète 100%. Et
+même si cela signifie plus de travail au début car ça peut exiger
+l'intervention des traducteurs si le code change, il est le meilleur moyen,
+à long terme, d'identifier ce qui a déjà été traduit et ce qui n'a pas, lors
+de la vérification de l'intégrité des fichiers .po.
+
+_* /{Sauts de ligne}/
+
+Les textes traduits doivent avoir les mêmes sauts de lignes exactes que les
+textes originaux. Veillez appuyer sur "Entrée" ou tapez *{\n}* si elles
+apparaissent dans les fichiers originaux. Ces nouvelles lignes apparaissent
+souvent, par exemple, dans les blocs de code.
+
+Ne vous méprenez pas, cela ne signifie pas que le texte traduit doit avoir
+la même longueur que la version anglaise. C'est presque impossible.
+
+_* /{Chaînes intraduisibles}/
+
+Les traducteurs ne doivent jamais traduire:
+
+ - Les noms de code des versions (qui doivent être écrits en minuscules)
+
+ - Les noms des logiciels
+
+ - Les commandes fournies à titre d'exemples
+
+ - Métadonnées (souvent entre deux points *{:metadata:}*)
+
+ - Liens
+
+ - Les chemins