Bonjour et bonne année 2010,
Je viens de terminer la traduction de coreutils (le diff était seulement de 530 Ko :).
Voici quelques remarques générales dans le but de les corriger dans les traductions actuelles et de les éviter à l'avenir. Étant sur traduc.org, la majorité des personnes de cette liste doivent les connaître !
- je n'ai pas traduit les mots argument car une fois traduits ils augmentent la longueur des lignes (80 colonnes)
La traduction suivante devient alors illisible en français : #: src/chcon.c:352 #, c-format msgid "" "Usage: %s [OPTION]... CONTEXT FILE...\n" " or: %s [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...\n" " or: %s [OPTION]... --reference=RFILE FILE...\n" msgstr "" "Utilisation : %s [OPTION]... CONTEXT FILE...\n" " ou : %s [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] " "FILE...\n" " ou : %s [OPTION]... --reference=RFILE FILE...\n"
traduire RFILE par FICHIERR n'a pas beaucoup de sens et les mots s'éloignent alors des options auxquelles ils sont associés, par exemple, --range=INTERVALLE.
#: src/chcon.c:370 msgid "" " -u, --user=USER set user USER in the target security context\n" " -r, --role=ROLE set role ROLE in the target security context\n" " -t, --type=TYPE set type TYPE in the target security context\n" " -l, --range=RANGE set range RANGE in the target security context\n" "\n"
les mots clés en français laissent peu de place pour la partie explication et empêchent de maintenir l'alignement avec les autres options de l'application
- « invalid » se traduit par « non valide » (et non invalide) - attention à ne pas traduire les mots clés (j'ai trouvé des dizaines d'erreurs), si vous consultez l'aide « ls --help » de votre système, vous verrez certainement cette perle : --indicator-style=MOT ajouter en suffixe l'indicateur selon le MOT none (par défaut), barre oblique (-p) file-type (--file-type), classify (-F)
« --indicator-style=barre oblique » n'est pas vraiment une option !
- quand le mot doit rester en anglais, j'utilise la forme suivante : « slash » (barre oblique).
- Rapporter les anomalies -> Signalez les anomalies
- Attention aux espaces insécables et aux chevrons français !
- User -> Utilisateur (et non l'affreux usager)
- 3e forme de l'infinitif pour les descriptions d'options : -r, --reverse inverse l'ordre de tri -R, --recursive liste récursivement les sous-répertoires
- je trouve plus élégant de traduire les messages d'erreur par : « impossible de ... » que par « ne peut pas créer le » ou encore « échec de création du ... »
#: lib/mkdir-p.c:206 src/copy.c:1890 src/install.c:705 src/install.c:718 #, c-format msgid "cannot create directory %s" msgstr "impossible de créer le répertoire %s"
- si vous avez un doute sur le mot utilisez, http://glossaire.traduc.org !
- n'hésitez pas à placer des commentaires dans les fichiers PO (pour détaillé ou justifiez vos choix, placer un FIXME, etc).
- traduire FIFO par PEPS, n'aide en aucun cas l'utilisateur final !
Bonne année à tous, Stéphane
Afficher les réponses par date
Le 2009-01-03 14:52:16 +0100, Stéphane Raimbault écrivait :
Bonjour et bonne année 2010,
Merci. Bonne année 2010 à tous également !
Je viens de terminer la traduction de coreutils (le diff était seulement de 530 Ko :).
Beau boulot.
Voici quelques remarques générales dans le but de les corriger dans les traductions actuelles et de les éviter à l'avenir. Étant sur traduc.org, la majorité des personnes de cette liste doivent les connaître !
- je n'ai pas traduit les mots argument car une fois traduits ils
augmentent la longueur des lignes (80 colonnes)
La traduction suivante devient alors illisible en français : #: src/chcon.c:352 #, c-format msgid "" "Usage: %s [OPTION]... CONTEXT FILE...\n" " or: %s [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...\n" " or: %s [OPTION]... --reference=RFILE FILE...\n" msgstr "" "Utilisation : %s [OPTION]... CONTEXT FILE...\n" " ou : %s [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] " "FILE...\n" " ou : %s [OPTION]... --reference=RFILE FILE...\n"
traduire RFILE par FICHIERR n'a pas beaucoup de sens et les mots s'éloignent alors des options auxquelles ils sont associés, par exemple, --range=INTERVALLE.
#: src/chcon.c:370 msgid "" " -u, --user=USER set user USER in the target security context\n" " -r, --role=ROLE set role ROLE in the target security context\n" " -t, --type=TYPE set type TYPE in the target security context\n" " -l, --range=RANGE set range RANGE in the target security context\n" "\n"
les mots clés en français laissent peu de place pour la partie explication et empêchent de maintenir l'alignement avec les autres options de l'application
Je suis globalement d'accord avec tout ce qui est dit là, sauf sur le point ci-dessus. Cela dit, ce n'est que mon avis personnel qui n'engage que moi :
- Pour moi, il est important de traduire les arguments, quitte à les abréger, pour qu'ils soient compréhensibles par un lecteur francophone.
- Il est par contre effectivement aussi important de vérifier que l'on reste bien dans les limites des 80 colonnes (i.e. max. 79) et que l'alignement des colonnes est toujours correct.
Cela dit, ce n'est pas moi qui me suis tapé le boulot :)
À bientôt !
Bonjour,
J'aimerais rebondir sur le message de Stéphane Raimbault à qui j'avais répondu en privé sur quelques points de traduction.
[Si j'ai répondu en privé, c'est parce que je ne me sentais pas le droit d'utiliser la liste traduc pour discuter de points techniques et que je ne voyais pas où poster mon message sinon : à vrai dire quel aurait été le bon support pour ce genre de discussions (la liste traduc-po semble par exemple réservée en écriture aux robots) ?]
Sur la suggestion de Stéphane, je fais ma réponse sur traduc mais cela repose à mon avis la question de trouver la méthode optimale pour permettre aux traducteurs de bénéficier de retours de la part de relecteurs (Jean-Christophe Helary parlait par exemple de la mise en place de couples traducteur/relecteur - si jamais ce n'était pas déjà le cas).
Stéphane Raimbault a écrit :
Hugo Herbelin a écrit :
...
Comme pour --indicator-style, les arguments de l'option --format sont des mots anglais (across, long, horizontal, etc.) qui ne doivent donc pas être traduits
Corrigé.
(d'ailleurs, à propos de l'option --indicator-style, j'ai l'impression que c'est du style de l'indicateur qu'il est question plus que de l'indicateur de style : les mots « none », « slash », etc. déterminent si l'ajout d'un suffixe (parmi /=>@|) aux noms des fichiers obéit à la règle par défaut, à la règle donnée par -p ou à la règle donnée par --file-type).
La nuance n'est pas évidente à saisir, est-ce que la chaîne suivante convient :
--indicator-style=WORD ajoute un indicateur selon le style WORD aux noms des entrées :
ou à défaut, que proposez-vous ?
C'est difficile ! Voici pêle-mêle plusieurs propositions mais elles sont toutes un peu verbeuses (peut-être un peu trop ?).
--indicator-style=WORD détermine la règle d'ajout d'un suffixe indiquant le type de fichier : « none » (comportement par défaut sans suffixe),\n" « slash » (se comporte comme l'option -p),\n" « file-type » (se comporte comme l'option --file-type)\n" ou « classify » (se comporte comme l'option -F)\n"
--indicator-style=WORD indique quand utiliser un suffixe indiquant le type des fichiers, les choix possibles pour WORD sont : « none » (aucun suffixe, le défaut),\n" « slash » (comme avec -p),\n" « file-type » (comme avec --file-type)\n" ou « classify » (comme avec -F)\n"
--indicator-style=WORD WORD détermine quand utiliser un suffixe indiquant le type des fichiers : « none » (aucun suffixe, le défaut),\n" « slash » (comme avec -p),\n" « file-type » (comme avec --file-type)\n" ou « classify » (comme avec -F)\n"
--indicator-style=WORD détermine selon WORD quand utiliser un suffixe indiquant le type des fichiers : « none » (aucun suffixe, le défaut),\n" « slash » (comme avec -p),\n" « file-type » (comme avec --file-type)\n" ou « classify » (comme avec -F)\n"
L'anglais dit « entry » mais je trouve que « entrée » fait bizarre en français parce qu'il s'agit plus ici de sorties. Mais le risque avec « fichiers » c'est que ce soit l'acception stricte (qui exclut répertoires, liens, etc.) qui soit comprise. Ou alors chercher du côté de « item » ou « données » ?
Hugo Herbelin
Le 2009-01-03 20:30:18 +0100, herbelin écrivait :
J'aimerais rebondir sur le message de Stéphane Raimbault à qui j'avais répondu en privé sur quelques points de traduction.
[Si j'ai répondu en privé, c'est parce que je ne me sentais pas le droit d'utiliser la liste traduc pour discuter de points techniques et que je ne voyais pas où poster mon message sinon : à vrai dire quel aurait été le bon support pour ce genre de discussions (la liste traduc-po semble par exemple réservée en écriture aux robots) ?]
Sur la suggestion de Stéphane, je fais ma réponse sur traduc mais cela repose à mon avis la question de trouver la méthode optimale pour permettre aux traducteurs de bénéficier de retours de la part de relecteurs (Jean-Christophe Helary parlait par exemple de la mise en place de couples traducteur/relecteur - si jamais ce n'était pas déjà le cas).
La liste traduc est un bon endroit pour discuter de choix de traduction, aucun problème.
Stéphane Raimbault a écrit :
Hugo Herbelin a écrit :
(d'ailleurs, à propos de l'option --indicator-style, j'ai l'impression que c'est du style de l'indicateur qu'il est question plus que de l'indicateur de style : les mots « none », « slash », etc. déterminent si l'ajout d'un suffixe (parmi /=>@|) aux noms des fichiers obéit à la règle par défaut, à la règle donnée par -p ou à la règle donnée par --file-type).
La nuance n'est pas évidente à saisir, est-ce que la chaîne suivante convient :
--indicator-style=WORD ajoute un indicateur selon le style WORD aux noms des entrées :
ou à défaut, que proposez-vous ?
C'est difficile ! Voici pêle-mêle plusieurs propositions mais elles sont toutes un peu verbeuses (peut-être un peu trop ?).
--indicator-style=WORD détermine la règle d'ajout d'un suffixe indiquant le type de fichier : « none » (comportement par défaut sans suffixe),\n" « slash » (se comporte comme l'option -p),\n" « file-type » (se comporte comme l'option --file-type)\n" ou « classify » (se comporte comme l'option -F)\n"
--indicator-style=WORD indique quand utiliser un suffixe indiquant le type des fichiers, les choix possibles pour WORD sont : « none » (aucun suffixe, le défaut),\n" « slash » (comme avec -p),\n" « file-type » (comme avec --file-type)\n" ou « classify » (comme avec -F)\n"
--indicator-style=WORD WORD détermine quand utiliser un suffixe indiquant le type des fichiers : « none » (aucun suffixe, le défaut),\n" « slash » (comme avec -p),\n" « file-type » (comme avec --file-type)\n" ou « classify » (comme avec -F)\n"
--indicator-style=WORD détermine selon WORD quand utiliser un suffixe indiquant le type des fichiers : « none » (aucun suffixe, le défaut),\n" « slash » (comme avec -p),\n" « file-type » (comme avec --file-type)\n" ou « classify » (comme avec -F)\n"
Pourquoi pas :
--indicator-style=MOT ajoute un indicateur de type à chaque entrée, en respectant le style indiqué par MOT : « none » (aucun suffixe, par défaut),\n" « slash » (comme l'option -p),\n" « file-type » (comme l'option --file-type),\n" « classify » (comme l'option -F).\n"
Bonne soirée à tous !
Le 3 janvier 2010 23:30, Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org a écrit :
Le 2009-01-03 20:30:18 +0100, herbelin écrivait :
Sur la suggestion de Stéphane, je fais ma réponse sur traduc mais cela repose à mon avis la question de trouver la méthode optimale pour permettre aux traducteurs de bénéficier de retours de la part de relecteurs (Jean-Christophe Helary parlait par exemple de la mise en place de couples traducteur/relecteur - si jamais ce n'était pas déjà le cas).
La liste traduc est un bon endroit pour discuter de choix de traduction, aucun problème.
Nous avons un processus assez similaire pour le projet GNOME (http://l10n.gnome.org), certains traducteurs confirmés disposent du statut de relecteur. Un document relu est donc normalement conforme aux standards de qualité du projet. Toutefois quelques envois sur la liste ou entre personnes de la liste devraient suffire.
--indicator-style=MOT ajoute un indicateur de type à chaque entrée, en respectant le style indiqué par MOT : « none » (aucun suffixe, par défaut),\n" « slash » (comme l'option -p),\n" « file-type » (comme l'option --file-type),\n" « classify » (comme l'option -F).\n"
Je trouve cette formulation assez claire et pour revenir sur la remarque de Hugo concernant les « entrées » qui seraient plutôt des sorties, je dirais qu'il s'agit d'entrées du point de vue de l'application qui ensuite les affiche en sortie.
PS : j'ai intégré cette dernière proposition de traduction à coreutils :
--indicator-style=WORD ajoute un indicateur de type à chaque entrée, en respectant le style indiqué par WORD : « none » (aucun suffixe, par défaut), « slash » (barre oblique, comme l'option -p), « file-type » (type de fichier, comme --file-type) ou « classify » (classé, commme l'option -F)
« comme --file-type » et non « comme l'option --file-type » pour éviter un saut de ligne.
-
herbelin -
Jean-Philippe Guérard -
Stéphane Raimbault