Le Tue, 7 Jan 2003 15:45:09 +0100 Bernard Choppy choppy@imaginet.fr a écrit :
Le Lundi 6 Janvier 2003 23:07, Delanoy Frédéric a écrit :
Bonjour,
Bonjour à toi et à tous, et meilleurs voeux (au passage :-))
Pensez-vous qu'il faille apposer la marque du pluriel aux noms de cibles et d'acronymes, ou encore des noms de commandes ?
Non, il ne faut pas.
Quelqu'un dispose-t-il de références (liens) vers des documents explicitant ce type d'accord.
Ma bible : Règles typographiques en usage à l'Imprimerie nationale
Serait-ce par hasard accessible on-line ?
<...>
Déjà, il faut faire la chasse systématique aux majuscules abusives
Par exemple, pour les titres de section, seule la première lettre du premier mot doit être mise en majuscule (arrête-moi si je me trompe).
Du genre : "La Super-Section de la Mort qui Tue" -> "La super-section de la mort qui tue" Ce type de titre apparaît parfois dans les pages de manuel en anglais (gcc p.ex.)
Dans un autre registre, que faut-il faire quand (dans une page de manuel p.ex.), une réponse d'un programme est spécifiée :
<...>
Toujours laisser _à l'identique_ ce qui est technique (commandes, réponses de programmes, etc.), de telle manière qu'un copier-coller d'un extrait de code de la version traduite continue à fonctionner à l'identique.
Il est _très préférable_ de traduire les commentaires des programmes et le texte des exemples de scripts ou de programmes, comme par exemple :
# MyCmd.sh general purpose test script echo "Usage: mycmd.sh [file]" #Command usage
se traduit en :
# macommande.sh : script de test a usage general echo "Usage : macommande.sh [fichier]" #Utilisation de la commande
Dans ce cas précis, je laisserais plutôt MyCmd.sh puisque c'est le script à utiliser. En extrapolant, cela reviendrait à traduire le nom des fonctions C (p.ex estascii() au lieu de isascii()), ce qui n'est pas recommandable.
Notez que dans ce cas, l'usage de lettres accentuées _n'est pas conseillé_, afin d'éviter des effets de bord dans des environnements qui ne gèrent pas correctement le 8bit.
Pas sûr. L'utilisateur de versions traduites disposent en général d'un environnement 8 bits (l'ISO-8859-1 est quand même très répandu). Si ce n'est néanmoins pas le cas, il peut (est en général capable de) convertir les documents qu'il désire en utilisant différents utilitaires (tr(1) p.ex.). De plus, s'il est nécessaire de supprimer les accents des exemples de programmes, il faudrait également le faire pour le reste du document, ce qui "léserait" la plupart des utilisateurs.
Si la localisation existe, toujours se fonder sur la version localisée. N'oublions pas qu'il s'agit d'adaptation française et que le lecteur peut toujours accéder à la version en anglais de la documentation si la localisation n'est pas activée.
vs
Même remarque que précédemment : il ne faut pas traduire les commandes ni les réponses des programmes, que l'on fasse une traduction anglais->français ou petit nègre->français ;-))
Justement, tu viens de dire qu'il fallait "se fonder sur la version localisée" si elle existait. Faut-il alors DANS TOUS LES CAS se baser sur (=laisser telle quelle) la version anglaise ???
Un problème apparaîssant parfois même quand une localisation existe, c'est l'évolution des traductions du "localiseur". Ex: la page de manuel de mc(1) documente les éléments d'interface du programme. Or, entre deux versions de mc, la V.F. a changé -> c'est difficile de rester "synchronisé" avec la localisation. Si on laisse la V.O., le problème ne se pose pas, mais l'utilisateur est alors moins bien guidé.
Amitiés,
Itou