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.