diff options
Diffstat (limited to 'markup/pod/live-manual/media/text/fr/appendix_style-guide.ssi')
| -rw-r--r-- | markup/pod/live-manual/media/text/fr/appendix_style-guide.ssi | 390 |
1 files changed, 0 insertions, 390 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 deleted file mode 100644 index 7217a77..0000000 --- a/markup/pod/live-manual/media/text/fr/appendix_style-guide.ssi +++ /dev/null @@ -1,390 +0,0 @@ -: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 |