mirror of https://framagit.org/kyodev/kyopages.git
fix titrages
This commit is contained in:
kyodev
parent
36b708823e
commit
08cb54c41e
|
|
@ -3711,337 +3711,6 @@ nécessaire pour faire que le lanceur fonctionne correctement, est inclus par
|
|||
défaut.
|
||||
|
||||
|
||||
## 19. guide de style
|
||||
|
||||
### 19.1 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
|
||||
|
||||
|
||||
#### 19.1.1 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.
|
||||
|
||||
|
||||
#### 19.1.2 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 **buster** 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 [link: <http://www.sisudoc.org/>]
|
||||
pour traiter les fichiers texte et pour produire plusieurs formats. Il est
|
||||
recommandé de consulter le manuel SiSU [link:
|
||||
<http://www.sisudoc.org/sisu/en/html/sisu_manual/markup.html>] pour se
|
||||
familiariser avec son balisage, ou bien tapez:
|
||||
```shell
|
||||
$ sisu --help markup
|
||||
```
|
||||
Voici quelques exemples de balisage qui peuvent éventuellement vous aider:
|
||||
|
||||
- Pour accent/texte en gras: *{foo}* or !{foo}!
|
||||
il produit: `*foo*` or `*foo*`. Utiliser pour mettre l'accent sur certains mots-clés.
|
||||
|
||||
- Pour italique: /{foo}/
|
||||
il produit: `/foo/`. Utiliser par exemple, pour les noms des paquets Debian.
|
||||
|
||||
- Pour monospace: #{foo}#
|
||||
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:
|
||||
```text
|
||||
code{
|
||||
|
||||
$ foo
|
||||
# bar
|
||||
|
||||
}code
|
||||
```
|
||||
il produit:
|
||||
```text
|
||||
$ foo
|
||||
# bar
|
||||
```
|
||||
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.
|
||||
|
||||
|
||||
### 19.2 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. En
|
||||
particulier, la section Traduction
|
||||
|
||||
|
||||
#### 19.2.1 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 suspects 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
|
||||
|
||||
```text
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -4076,16 +3745,3 @@ Les traducteurs ne doivent jamais traduire:
|
|||
Dernière production du document (metaverse): 2016-07-04 23:09:19 +0000
|
||||
|
||||
==============================================================================
|
||||
|
||||
plaintext (plain text):
|
||||
http://debian-live.alioth.debian.org/manual/txt/live-manual.fr.txt
|
||||
Other versions of this document:
|
||||
manifest:
|
||||
http://debian-live.alioth.debian.org/manual/manifest/live-manual.fr.html
|
||||
at:
|
||||
http://debian-live.alioth.debian.org/manual
|
||||
* Generated by: SiSU 7.1.8 of 2016w08/5 (2016-02-26)
|
||||
* Ruby version: ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]
|
||||
* Last Generated on: 2016-07-04 23:09:28 +0000
|
||||
* SiSU www.sisudoc.org
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue