Bonjour,
j'aimerais connaître vos avis sur des "problématiques" revenant dans à peu près tous les types de traductions, et qui me posent (parfois) problème. (Rem : Si vous avez des liens intéressants, faites-les connaître...)
Pensez-vous qu'il faille apposer la marque du pluriel aux noms de cibles et d'acronymes, ou encore des noms de commandes ? Quelqu'un dispose-t-il de références (liens) vers des documents explicitant ce type d'accord.
Ex: des DLLs les différents TRUCMUCHs (voir trucmuch(1)) les différents Unix/Unixs/Unices les structs (structures dans le langage C) les directives #define, les #define(s?) ...
Pour ma part, je pense qu'il faudrait éliminer toutes ces marques du pluriel, bien qu'elles pourraient éventuellement être envisageables pour les termes en majuscule. Il me semble avoir vu quelque part que ces termes sont invariables, mais je peux me gourer.
Le débat est ouvert.
***** 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 : - laisser le message original et le traduire juste après (entre parenthèses p.ex.) ? - traduire et éliminer la phrase anglaise ? - ne laisser que la phrase anglaise (si le contexte environnant permet de déterminer sa signification : ex -> si vous faites ceci avec FICHIER, le programme dira "bla bla bla FICHIER glou glou glou")
sachant que : -tous les programmes ne sont pas locale-isés. -la localisation peut ne pas toujours être activée. -les situations entraînant ces réponses ne sont pas toujours triviales à reproduire. -même si elles sont triviales à reproduire, le traducteur ne dispose pas toujours de l'environnement nécessaire (p.ex. la bonne architecture). -la trad du "localiseur" et celle du traducteur peuvent parfois diverger, p.ex. en cas d'erreur dans celle du premier nommé : dans ce cas, des trads différentes pourraient rendre perplexe l'utilisateur ; même si la trad du localiseur est correcte, le traducteur peut ne pas en disposer.
Qu'en pensez-vous ?
Afficher les réponses par date
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
Ex: des DLLs les différents TRUCMUCHs (voir trucmuch(1))
Déjà, il faut faire la chasse systématique aux majuscules abusives : ici, il faut composer : les différents Trucmuch si Trucmuch est un nom propre.
Rappel : seuls les sigles se composent en capitales, séparées par des points si le sigle est en français. Exemple : la S.N.C.F. et la R.A.T.P., mais le FBI et la CIA (où vais-je chercher mes exemples, moi ?) ;-)))
Les abréviations se composent en minuscules (ex. : janv., fév. esc., bât., etc.) et les appellations commerciales avec une initiale majuscule sulement (on écrit donc Michelin, la Poste, Auchan et Carrefour ainsi qu'Oracle et Microsoft, mais IBM et NEC).
les différents Unix/Unixs/Unices
Unix (c'est une marque commerciale, de même qu'on doit écrire les Mégane si l'on parle de Mégane et de Mégane Scénic par exemple).
les structs (structures dans le langage C)
les struct (il s'agit d'un mot réservé du langage C, donc invariable. On le composera de préférence dans un corps différent, personnellement je le place en verbatim, donc police machine à écrire).
les directives #define, les #define(s?)
Idem.
Pour ma part, je pense qu'il faudrait éliminer toutes ces marques du pluriel, bien qu'elles pourraient éventuellement être envisageables pour les termes en majuscule. Il me semble avoir vu quelque part que ces termes sont invariables, mais je peux me gourer.
Ta mémoire est bonne.
Le débat est ouvert.
Euh... pas vraiment, je crois. Il s'agit de règles bien établies maintenant, sauf erreur de ma part.
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 :
- laisser le message original et le traduire juste après (entre
parenthèses p.ex.) ?
- traduire et éliminer la phrase anglaise ?
- ne laisser que la phrase anglaise (si le contexte environnant permet
de déterminer sa signification : ex -> si vous faites ceci avec FICHIER, le programme dira "bla bla bla FICHIER glou glou glou")
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
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.
sachant que : -tous les programmes ne sont pas locale-isés. -la localisation peut ne pas toujours être activée.
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.
Éventuellement, ajouter une note du traducteur pour guider le lecteur débutant.
(...)
-la trad du "localiseur" et celle du traducteur peuvent parfois diverger, p.ex. en cas d'erreur dans celle du premier nommé : dans ce cas, des trads différentes pourraient rendre perplexe l'utilisateur ;
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 ;-))
C'est donc le localiseur qui a la main (ou alors, il faut reprendre et faire valider la localisation du programme, ce qui est sans doute souvent possible, sauf si le localiseur est paranoïaque, ce qui arrive aussi ;-)))
Qu'en pensez-vous ?
Ben... Tout ça, quoi :-)
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
Le Mercredi 8 Janvier 2003 12:47, Delanoy Frédéric a écrit :
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 :
Ma bible : Règles typographiques en usage à l'Imprimerie nationale
Serait-ce par hasard accessible on-line ?
Ce serait trop beau :-)) Mais je crois que ce n'est pas très cher et cela doit se trouver dans toutes les bonnes crèmeries (comme disait le regretté René Cougnenc).
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.)
Précisément.
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.
Dans ce cas précis et dans mon esprit, non, car il s'agit d'un script qui ne préexiste pas mais que le lecteur peut réaliser lui-même.
Bien sûr, lorsque le script préexiste (dans un paquetage, par exemple), il ne faut bien sûr pas traduire, AMHA.
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
Non, se fonder (la Marine nationale est basée à Brest mais il faut se fonder sur la version localisée) :-))
(=laisser telle quelle) la version anglaise ???
Dans mon esprit, si une localisation existe, il faut tenter de suivre celle-ci, même si sa localisation laisse à désirer, quitte à améliorer la localisation du paquetage en question.
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é.
C'est toute la difficulté du modèle "bazar" par rapport au modèle "cathédrale". Il faut bien qu'il y ait quelques désagréments ;-)
Cent fois sur le métier remettez votre ouvrage...
Bon courage !
Le Tue, 7 Jan 2003 15:45:09 +0100 Bernard Choppy choppy@imaginet.fr a écrit :
[...]
Ma bible : Lexique des règles typographiques en usage à l'Imprimerie nationale
ISBN 2-7433-0482-0 pour ceux que ça intéresse.
[...]
Rappel : seuls les sigles se composent en capitales, séparées par des points si le sigle est en français. Exemple : la S.N.C.F. et la R.A.T.P., mais le FBI et la CIA (où vais-je chercher mes exemples, moi ?) ;-)))
(Rem : T'as oublié la NSA...)
Justement, je viens de me procurer l'ouvrage susmentionné, et il indique pour sigles : « En ce qui concerne leur écriture, la seule unification possible et applicable à tous les cas est l'emploi de lettres capitales sans points ; outre le cas de nombreux sigles de formation syllabique excluant la présence de points, ceux qui pourraient en comporter n'en sont qu'inutilement et inestéthiquement allongés. » Comme exemple, il y a entre autres "RATP"
De même, sous "Sociétés (noms de)", il est écrit : « Les sigles des sociétés, associations, compagnies, etc., seront composées en grandes capitales collées sans points. Les sigles longs mais "prononçables" s'écriront de préférence en bas de casse avec capitale initiale : SPA, SNCF, Saviem, Snecma, Sofirad... »
Il n'est par contre pas fait mention d'une distinction entre "sigles français" et "sigles étrangers" (ou alors j'ai mal lu). (Mêmes règles qu'en français)
Les abréviations se composent en minuscules (ex. : janv., fév. esc., bât., etc.) [...]
Pas forcément, ex : N.D.T. (note du traducteur), QG, N.B., N.D.L.R., ...
Amitiés,
Itou
Le Vendredi 31 Janvier 2003 14:26, Frédéric Delanoy a écrit :
Le Tue, 7 Jan 2003 15:45:09 +0100 Bernard Choppy choppy@imaginet.fr a écrit :
Ma bible : Lexique des règles typographiques en usage à l'Imprimerie nationale
ISBN 2-7433-0482-0 pour ceux que ça intéresse.
(...)
Justement, je viens de me procurer l'ouvrage susmentionné, et il indique pour sigles : « En ce qui concerne leur écriture, la seule unification possible et applicable à tous les cas est l'emploi de lettres capitales sans points ; outre le cas de nombreux sigles de formation syllabique excluant la présence de points, ceux qui pourraient en comporter n'en sont qu'inutilement et inestéthiquement allongés. » Comme exemple, il y a entre autres "RATP"
De même, sous "Sociétés (noms de)", il est écrit : « Les sigles des sociétés, associations, compagnies, etc., seront composées en grandes capitales collées sans points. Les sigles longs mais "prononçables" s'écriront de préférence en bas de casse avec capitale initiale : SPA, SNCF, Saviem, Snecma, Sofirad... »
Oups ! Il va sans doute falloir que je m'offre une version mise à jour, la mienne doit être un peu trop ancienne...
Il n'est par contre pas fait mention d'une distinction entre "sigles français" et "sigles étrangers" (ou alors j'ai mal lu). (Mêmes règles qu'en français)
Les abréviations se composent en minuscules (ex. : janv., fév. esc., bât., etc.) [...]
Pas forcément, ex : N.D.T. (note du traducteur), QG, N.B., N.D.L.R., ...
Euh... Ce sont des sigles (uniquement l'initiale de chaque mot) et non des abréviations (mots dont ne sont présents que les premières lettres)...
From: "Bernard Choppy" choppy@imaginet.fr Sent: Friday, January 31, 2003 9:06 PM
Le Vendredi 31 Janvier 2003 14:26, Frédéric Delanoy a écrit :
Le Tue, 7 Jan 2003 15:45:09 +0100 Bernard Choppy choppy@imaginet.fr a écrit :
Les abréviations se composent en minuscules (ex. : janv., fév. esc., bât., etc.) [...]
Pas forcément, ex : N.D.T. (note du traducteur), QG, N.B., N.D.L.R., ...
Euh... Ce sont des sigles (uniquement l'initiale de chaque mot) et non des abréviations (mots dont ne sont présents que les premières lettres)...
Concernant les sigles d'expressions communes, la situation n'est pas claire, car il semble que l'esthétique compte pour beaucoup concernant l'absence ou la présence des points, ou l'usage des majuscules sur chaque initiale ainsi abrégée.
Ainsi, on trouve régulièrement Q.G. (Quartier Général) quand cela ne se réfère pas à une dénomination officielle (par exemple l'expression journalistique impropre "le Q.G. de la Police" quand il s'agit d'une structure informelle ou dont la dénomination officielle est changeante ou mal connue, alors que la forme QG est plutôt une abbréviation (!!!) d'un sigle officiel (lui aussi normalement écrit sans point).
On trouve aussi régulièrement la forme "NDT" (et souvent aussi "NdT") au milieu d'une phrase dans une note entre parenthèses, le sigle étant suivi d'une fine insécable, d'un deux-points et d'une espace avant la note. Les majuscules minuscules de tels sigles sont alors moins clairement définies, et dont parfois mixées, seuls les mots importants de l'expression ainsi réduite étant indiqués par une majuscule. Là encore cet usage est surtout journalistique dans un article.
Pour "N.B." (nota bene) les deux points sont requis pour ne pas confondre le sigle avec l'abréviation "nb." ou "Nb." de "nombre" (l'abréviation recommandée étant plutôt "nbr.").
Pour "N.D.L.R.", ces points sont très souvent supprimés dans "NDLR" dans une note parenthésée au milieu d'une phrase, comme pour "NdT" ou "NDT", afin de ne pas alourdir la ponctuation de la phrase...
Ces règles de suppression de points sur les sigles sont valables chaque fois que le sigle de l'expression commune, utilisant le plus souvent les majuscules, n'est pas prononçable, comme pour les noms de Sociétés (RATP, SNCF).
-
Bernard Choppy -
Delanoy Frédéric -
Frédéric Delanoy
-
Philippe Verdy