Re: Relecture du fichier PO

[Damien Heurtebise]

       Jean-Charles Malahieude wrote:
    > C'est vrai que ce message est un peu fastidieux à lire (d'ailleurs, ce
    > serait plus simple de faire un patch commenté, je peux te donner des
    > indications si tu veux à nouveau réviser ce PO)

Volontiers. Autant que ma relecture n'alourdisse pas le travail des
traducteurs !

    Il est en effet important de faire part à tous (et au moins à celui qui
    à fait la dernière mise à jour et qui se trouve automatiquement
    mentionné à la ligne "Last-Translator:" en début de fichier) de ses
    commentaires et corrections.

Très juste. Je me suis adressé à John car c'était sur son invitation que
j'ai entrepris cette relecture mais j'aurais pu réfléchir une seconde de
plus. Mea culpa. :-/
   
    >> lignes 1540, 1550 et 1557
    >>                 msgid "Initiate first voice",
    >>                 msgid "Initiate second voice"
    >>                 msgid "Initiate third voice"
    >> = "Début de la Nième voix" me paraît plus simple que "Initialisation
de la Nième voix"
    >
    > En effet, nous ne sommes pas obligés d'utiliser systématiquement un
    > vocabulaire informatique.
    J'opterais plutôt pour "création" dans la mesure où cette Nième voix
    n'existait pas auparavant.

Effectivement, "création" est encore plus précis.

    >> il serait plus clair de traduire les variables par quelque chose
comme
    >> "MusiqueClavierUnVoixUn", etc., au lieu de "ManuelUnVoixUnMusique".
De
    >> même, juste en dessous, traduire par "MusiquePedalierOrgue" plutôt
que
    >> "PedalierOrgueMusique".
    >
    > D'accord pour mettre "Musique" en tête.
    >
    Là, c'est mon habitude de travailler sur de la musique chorale en
    utilisant le mode LilyPond avec emacs : menu-LilyPond / Add-index-menu
    ajoute un menu supplémentaire où mes différentes variables sont rangées
    par ordre alphabétique. Je peux alors avoir "TenorMusique" et
    "TenorParoles" à la suite, au lieu de "MusiqueAlto" "MusiqueBasse"...

Alors que, si l'on inverse l'ordre des termes, on aura d'abord toutes les
voix ensemble ("MusiqueAlto", "MusiqueBasse"...) puis les paroles
("ParolesAlto", "ParolesBasse"...). Les deux se défendent. Spontanément et
pour une question de langage, je préfèrerais mettre "Musique" et "Paroles"
en premier mais le plus important est de rester cohérent avec le reste de la
doc.

    >> ligne 2174 (commentaire 1418), etc.
    >> = lorsque la ligne est trop longue, il semble que la traduction ne
    >> soit pas à sa place et qu'il y ait deux guillemets en trop. C'est
    >> volontaire ?
    >
    > C'est une convention de formatage du PO : les guillemets non échappés
    > sont de simples délimiteurs de chaînes de caractères, il ne font pas
    > partie de la chaîne elle-même.  Ceci permet de scinder des chaînes sur
    > plusieurs lignes lorsqu'elles sont longues.  Dans ce cas précis, les 2
    > guillemets consécutifs ne servent à rien.

Je flairais une explication de ce genre. C'est noté.

    >> ligne 2224 (commentaire 1979)
    >>                 msgid "This markup is short enough to fit without
collision"
    >> = faut-il maintenir la traduction de "markup" par "étiquette" ? Pour
    >> une fois, je suis partisan de garder le terme anglais car je trouve
    >> que le mot "étiquette" ne rend pas les choses plus claires. Dans ce
    >> cas, il faut aussi mettre à jour le commentaire suivant.
    >
    > J'ai traduit par "morceau de texte", mais lorsque la commande \markup
    > est utilisée, je suis d'accord pour employer "markup" lorsqu'on
désigne
    > un morceau de texte \markup particulier.
    >
    Ce terme n'a pas fini de faire couler de l'encre, ni de soulever des
    questionnements pseudo philosophiques quant à sa traduction (étiquette,
    commentaire, info-bulle...).
 
En effet, si nous avions besoin d'un troll sur la liste, la traduction de
"markup" en fournirait un idéal !

    >> lignes 3556 et 3563
    >>                 msgid "Problems with convert-ly"
    >>                 msgid "Problems with @code{convert-ly}"
    >> = je préfère "Limites de convert-ly" plutôt que "Limitations"
    >
    > Pourquoi ?

D'après Le Robert, le terme "limitation" désigne l'action de limiter, de
fixer volontairement des limites puis, par extension, il désigne le résultat
de cette action (les limitations de vitesse, par exemple). Au contraire, le
terme "limite" désigne le maximum des possibilités d'une personne (ou ici
d'un programme), déterminé par ses capacités propres (comme dans
l'expression "atteindre ses limites"). Les problèmes rencontrés lors de
l'utilisation de convert-ly ne sont pas dus à une volonté des programmeurs
mais aux capacités limités de la machine, qui ne peut pas trouver dans le
code des précisions qui n'y figurent pas.

A bientôt.
Damien 
-- 
View this message in context: 
http://n2.nabble.com/Re%3A-Relecture-du-fichier-PO-tp1477517p1493284.html
Sent from the LilyPond French Users mailing list archive at Nabble.com.