remarques de traduction : chapitre 7 "Notation spécifique" du manuel

Bonjour à tous,

Un grand merci aux traducteurs, qui prennent sur leur temps libre pour accompli cette tâche.

Bien que n'étant pas traducteur "officiel" du manuel, j'ai suivi le conseil de John : lecture des guides sur le site

http://wiki.traduc.org/Guides_de_traduction

Le lien sur le guide pratique de SUN est très instructif, notamment pour les différences de mentalité entre américains et latins, ainsi que l'utilisation de la voix active

Donc voici mes remarques sur ce chapitre, en toute simplicité et sans dénigrer le travail accompli.
Le signe "=" propose un remplacement chaîne pour chaîne.
Le signe ":" est suivi de remarques

7.1
Les portées sont largement autonomes : remplacer "Les portées" par "Elles"

Cette notation sert également à la harpe ou à d'autres instruments à clavier : cette phrase serait plus logique en tête de paragraphe

Le contexte PianoStaff <http://john.mandereau.free.fr/lilypond-doc/Documentation/user/lilypond-internals/PianoStaff.fr.html#PianoStaff&gt; est précisément conçu pour gérer ces croisements ; cela fait l'objet de cette section, ainsi que d'autres écritures pianistiques. = Le contexte PianoStaff <http://john.mandereau.free.fr/lilypond-doc/Documentation/user/lilypond-internals/PianoStaff.fr.html#PianoStaff&gt; est précisément conçu pour gérer la notation spécifique au piano, principalement ces croisements.

7.1.1
On peut permettre aux voix de = les voix peuvent
aussi vaut-il mieux, si besoin, mettre = il est préférable de mettre
il vaut mieux spécifier soi-même ces changements. = spécifiez vous-même ces changements.

7.1.2
Il est possible de passer d'une portée à l'autre de façon manuelle, au moyen de la commande = Ils sont (réalisés OU imposés OU forcés) par la commande

Dans bien des cas, nomDeLaPortee pourra être |"haut"| ou |"bas"|. : précision habituelle dans une documentation anglo-saxonne, est-elle réellement pertinente ?
dans la négative le "Quoi qu'il en soit," qui suit est superflu.

7.1.3
Le piano possède des pédales qui permettent de modifier l'émission du son. Ces pédales sont au nombre de deux, auxquelles s'ajoute parfois une troisième pédale. =
Le piano possède deux, parfois trois, pédales qui permettent de modifier l'émission du son.

On peut régler de quelle manière ces indications seront imprimées, en définissant |pedal|X|Strings = |l'impression de ces indications est définie par la propriété |pedal|X|Strings|

et ce au moyen des propriétés |edge-width|, = en modifiant la valeur des propriétés |edge-width|,

7.1.4
il est possible d'imprimer automatiquement une ligne reliant les notes = une ligne reliant les notes peut être imprimée automatiquement
en définissant comme vraie = "en positionnant à VRAI" ou "en attribuant la valeur VRAI" REMARQUE : VRAI est une valeur informatique booléenne opposée à FAUX, elle ne s'accorde ni en genre ni en nombre

7.1.5
On peut écrire des accords qui enjambent deux portées, en allongeant la hampe de l'une des deux portées de façon à ce qu'elle rejoigne celle de l'autre portée. = pour écrire des accords enjambant deux portées, allongez la hampe des notes de l'une des deux portées pour qu'elle rejoigne la hampe des notes l'autre portée

···

**********************************
FIN DES REMARQUES
**********************************

Merci encore pour votre courage et votre ouvrage de traduction

P.E. Brame

Bonjour

Beau boulot, bien plus agréable à consulter en Français.

deux corrections vraiment mineures

7.1 Musique pour piano

Les systèmes de piano comprennent deux portées réunies par une accolade. % peut-être
Les partitions de piano comportent deux portées réunies par une accolade. % ou
Les deux portées du piano sont réunies par une accolade.

7.1.3 Pédales
(à la fin)

Voir aussi

Dans ce même manuel : Liaisons ``laissez vibrer'' % au lieu de
Dans ce même manuel : Liaisons "laissez vibrer" % ou bien
Dans ce même manuel : Liaisons 'laissez vibrer'

   Amicalement

Marc Lanoiselée

Bonjour à tous,

Un grand merci aux traducteurs, qui prennent sur leur temps libre pour
accompli cette tâche.

Bien que n'étant pas traducteur "officiel" du manuel, j'ai suivi le
conseil de John : lecture des guides sur le site

Il n'y a pas de traducteur officiel :slight_smile: : il n'y a que des traducteurs
et relecteurs de fait.

J'ai apporté tous les changements ci-dessous aux sources de LilyPond,
dans la branche lilypond/translation (qui sera fusionnée avec la branche
de développement dans quelques jours). Vous pouvez voir *tous* les
changements sur
http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=lilypond/translation en cliquant sur les liens "commitdiff".
J'en ai profité pour corriger la casse jusqu'à la section 7.1.5 :
"clé de Fa" -> "clé de fa"
"Référence du Programme" -> "Référence du programme"
"Voyez la Référence du Programme" -> "Voyez la référence du programme"

Donc voici mes remarques sur ce chapitre, en toute simplicité et sans
dénigrer le travail accompli.
Le signe "=" propose un remplacement chaîne pour chaîne.
Le signe ":" est suivi de remarques

J'utilise aussi "=".

7.1
Les portées sont largement autonomes : remplacer "Les portées" par "Elles"

On y gagnerait en élégance, mais peut-être pas en clarté.

Cette notation sert également à la harpe ou à d'autres instruments à
clavier : cette phrase serait plus logique en tête de paragraphe

Il me semble important de décrire cette notation (c'est l'objet des 2
premières phrases) avant de dire pour quels instruments on l'utilise.
Je serais plutôt pour renommer la section en "Musique pour clavier", ou
mieux "Instruments utilisant une portée double" ; qu'en pensez-vous ?

Le contexte PianoStaff
<http://john.mandereau.free.fr/lilypond-doc/Documentation/user/lilypond-internals/PianoStaff.fr.html#PianoStaff&gt;
est précisément conçu pour gérer ces croisements ; cela fait l'objet de
cette section, ainsi que d'autres écritures pianistiques. = Le contexte
PianoStaff
<http://john.mandereau.free.fr/lilypond-doc/Documentation/user/lilypond-internals/PianoStaff.fr.html#PianoStaff&gt;
est précisément conçu pour gérer la notation spécifique au piano,
principalement ces croisements.

="Le contexte @internalsref{PianoStaff} est précisément
conçu pour gérer la notation spécifique au piano, notamment ces croisements."

7.1.1
On peut permettre aux voix de = les voix peuvent
aussi vaut-il mieux, si besoin, mettre = il est préférable de mettre

C'est corrigé.

il vaut mieux spécifier soi-même ces changements. = spécifiez vous-même
ces changements.

Je cite Documentation/user/README.txt (dans les sources) :
"""
* Do not explicitly refer to the reader/user. There is no one else
  besides the reader and the writer.
"""

Il me semble que cette recommandation de style s'applique sans problème
au manuel en français. J'ai juste remplacé "spécifier" par "indiquer" :
"il vaut mieux indiquer soi-même ces changements."

7.1.2
Il est possible de passer d'une portée à l'autre de façon manuelle, au
moyen de la commande = Ils sont (réalisés OU imposés OU forcés) par la
commande

Dans bien des cas, nomDeLaPortee pourra être |"haut"| ou |"bas"|. :
précision habituelle dans une documentation anglo-saxonne, est-elle
réellement pertinente ?

Oui ! Il est important de préciser que comme ce sont des noms de
contextes, ils sont arbitraires, i.e. définis par l'utilisateur. J'ai
reformulé tout le paragraphe :

"La valeur @var{nomDeLaPortee} est le nom de la portée sur laquelle va se
déplacer la voix courante. Pour des raisons pratiques, on nomme la portée
supérieure @code{"haut"} et la portée inférieure @code{"bas"}, donc
@var{nomDeLaPortee} désigne habituellement @code{"haut"} ou
@code{"bas"}. Dans tous les cas, le contexte de portée ainsi utilisé
doit exister au préalable. C'est pourquoi il est d'usage de commencer
par définir les portées"

7.1.3
Le piano possède des pédales qui permettent de modifier l'émission du
son. Ces pédales sont au nombre de deux, auxquelles s'ajoute parfois une
troisième pédale. =
Le piano possède deux, parfois trois, pédales qui permettent de modifier
l'émission du son.

="Le piano possède deux pédales, parfois trois, permettant de modifier
l'émission du son."

J'ai aussi mis les commandes dans un tableau, pour que ce soit plus concis.

On peut régler de quelle manière ces indications seront imprimées, en
définissant |pedal|X|Strings = |l'impression de ces indications est
définie par la propriété |pedal|X|Strings|

="Les modalités d'impression de ces indications sont définies par la
propriété @code{pedal@var{X}Strings}"

et ce au moyen des propriétés |edge-width|, = en modifiant la valeur des
propriétés |edge-width|,

Qu'apporte cette reformulation ?

7.1.4
il est possible d'imprimer automatiquement une ligne reliant les notes =
une ligne reliant les notes peut être imprimée automatiquement

Pourquoi revenir à la voix passive ?

en définissant comme vraie = "en positionnant à VRAI" ou "en attribuant
la valeur VRAI"
REMARQUE : VRAI est une valeur informatique booléenne opposée à FAUX,
elle ne s'accorde ni en genre ni en nombre

En effet. À propos, quelle est la typographie appropriée pour ce "vrai" ?
« vrai » (entre guillemets)
/vrai/ (en italique)
Je préfère l'italique, mais est-ce correct ?

7.1.5
On peut écrire des accords qui enjambent deux portées, en allongeant la
hampe de l'une des deux portées de façon à ce qu'elle rejoigne celle de
l'autre portée. = pour écrire des accords enjambant deux portées,
allongez la hampe des notes de l'une des deux portées pour qu'elle
rejoigne la hampe des notes l'autre portée

="Pour écrire des accords qui enjambent deux portées, on allonge la hampe
de l'une des deux portées de façon à ce qu'elle rejoigne celle de
l'autre portée."

Merci pour toutes ces remarques

···

Le vendredi 27 juillet 2007 à 21:08 +0200, P.E. Brame a écrit :
--
John Mandereau <****@****>

7.1.3 Pédales
(à la fin)

Voir aussi

Dans ce même manuel : Liaisons ``laissez vibrer'' % au lieu de

C'est bien l'alternative ci-dessus qui est produite dans la
documentation.

Dans ce même manuel : Liaisons "laissez vibrer" % ou bien
Dans ce même manuel : Liaisons 'laissez vibrer'

Des guillemets français « .. » seraient préférables, mais Texinfo (le
logiciel qui produit la documentation) ne les prend en charge uniquement
dans le texte courant, en taille 12, donc ça ne marche pas pour les
titres. Le code source à l'origine de

Liaisons ``laissez vibrer''

est aussi à l'origine d'un titre, d'où le problème.

Merci pour ce commentaire
John

···

Le vendredi 27 juillet 2007 à 23:04 +0200, Marc Lanoiselée a écrit :

Bonjour à tous,

Suite à mes remarques de traduction :

- la valeur VRAI : sa typographie est en effet une bonne question.
Informatiquement parlant, c'est une constante, l'usage (hérité du C) veut qu'elles soient en MAJUSCULE pour les différencier des variables.
Cependant scheme et python (utilisés entre autre pour coder lilypond) possèdent des mots clefs ( #t, True, #f, False) en minuscule pour ces deux valeurs.
Donc au choix, pourvu qu'il n'y ai pas d'ambiguïté entre la valeur et l'adjectif.

7.1.5 :
Je persiste, les hampes appartiennent aux notes et non aux portées !

Merci encore

P.E. Brame

Le 30.07.2007 11:11, John Mandereau disait :

Bonjour à tous,

7.1.5
On peut écrire des accords qui enjambent deux portées, en allongeant la hampe de l'une des deux portées de façon à ce qu'elle rejoigne celle de l'autre portée. = pour écrire des accords enjambant deux portées, allongez la hampe des notes de l'une des deux portées pour qu'elle rejoigne la hampe des notes l'autre portée

="Pour écrire des accords qui enjambent deux portées, on allonge la hampe
de l'une des deux portées de façon à ce qu'elle rejoigne celle de
l'autre portée."

En fait, j'ai une préférence pour la proposition originale de Valentin et moi-même :
- Rien ne stipule que les hampes appartiennent à une porté ou l'autre.
   C'est juste là qu'elles se situent géographiquement.
- Nous utilisons un « pluriel générique » en parlant de hampe plutôt
   que de note : on peut avoir une hampe à 2 notes en clé de sol ET une
   hampe à 1 note seulement en clé de fa, mais ce n'est que le fait que
   les hampes soient reliées qui donnent l'indication au pianiste.

Jean-Charles

···

Le vendredi 27 juillet 2007 à 21:08 +0200, P.E. Brame a écrit :

Le 30.07.2007 11:11, John Mandereau disait :

Bonjour à tous,

Un grand merci aux traducteurs, qui prennent sur leur temps libre pour accompli cette tâche.

Bien que n'étant pas traducteur "officiel" du manuel, j'ai suivi le conseil de John : lecture des guides sur le site

Il n'y a pas de traducteur officiel :slight_smile: : il n'y a que des traducteurs
et relecteurs de fait.

J'ai apporté tous les changements ci-dessous aux sources de LilyPond,
dans la branche lilypond/translation (qui sera fusionnée avec la branche
de développement dans quelques jours). Vous pouvez voir *tous* les
changements sur
http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=lilypond/translation en cliquant sur les liens "commitdiff".
J'en ai profité pour corriger la casse jusqu'à la section 7.1.5 :
"clé de Fa" -> "clé de fa"
"Référence du Programme" -> "Référence du programme"
"Voyez la Référence du Programme" -> "Voyez la référence du programme"

Donc voici mes remarques sur ce chapitre, en toute simplicité et sans dénigrer le travail accompli.
Le signe "=" propose un remplacement chaîne pour chaîne.
Le signe ":" est suivi de remarques

J'utilise aussi "=".

7.1
Les portées sont largement autonomes : remplacer "Les portées" par "Elles"

On y gagnerait en élégance, mais peut-être pas en clarté.

Cette notation sert également à la harpe ou à d'autres instruments à clavier : cette phrase serait plus logique en tête de paragraphe

Il me semble important de décrire cette notation (c'est l'objet des 2
premières phrases) avant de dire pour quels instruments on l'utilise.
Je serais plutôt pour renommer la section en "Musique pour clavier", ou
mieux "Instruments utilisant une portée double" ; qu'en pensez-vous ?

Le contexte PianoStaff <lien> est précisément conçu pour gérer ces croisements ; cela fait l'objet de cette section, ainsi que d'autres écritures pianistiques. = Le contexte PianoStaff <lien> est précisément conçu pour gérer la notation spécifique au piano, principalement ces croisements.

="Le contexte @internalsref{PianoStaff} est précisément
conçu pour gérer la notation spécifique au piano, notamment ces croisements."

et pourquoi pas « notation spécifique aux claviers » ?

7.1.2
Il est possible de passer d'une portée à l'autre de façon manuelle, au moyen de la commande = Ils sont (réalisés OU imposés OU forcés) par la commande

Dans bien des cas, nomDeLaPortee pourra être |"haut"| ou |"bas"|. : précision habituelle dans une documentation anglo-saxonne, est-elle réellement pertinente ?

Oui ! Il est important de préciser que comme ce sont des noms de
contextes, ils sont arbitraires, c.-a-d. définis par l'utilisateur. J'ai
reformulé tout le paragraphe :

"La valeur @var{nomDeLaPortee} est le nom de la portée sur laquelle va se
déplacer la voix courante. Pour des raisons pratiques, on nomme la portée
supérieure @code{"haut"} et la portée inférieure @code{"bas"}, donc
@var{nomDeLaPortee} désigne habituellement @code{"haut"} ou
@code{"bas"}. Dans tous les cas, le contexte de portée ainsi utilisé
doit exister au préalable. C'est pourquoi il est d'usage de commencer
par définir les portées"

Mieux.

7.1.3
Le piano possède des pédales qui permettent de modifier l'émission du son. Ces pédales sont au nombre de deux, auxquelles s'ajoute parfois une troisième pédale. =
Le piano possède deux, parfois trois, pédales qui permettent de modifier l'émission du son.

="Le piano possède deux pédales, parfois trois, permettant de modifier
l'émission du son."

J'ai aussi mis les commandes dans un tableau, pour que ce soit plus concis.

On peut régler de quelle manière ces indications seront imprimées, en définissant |pedal|X|Strings = |l'impression de ces indications est définie par la propriété |pedal|X|Strings|

="Les modalités d'impression de ces indications sont définies par la
propriété @code{pedal@var{X}Strings}"

Mieux.

et ce au moyen des propriétés |edge-width|, = en modifiant la valeur des propriétés |edge-width|,

Qu'apporte cette reformulation ?

Il est possible de d'affiner l'apparence d'un crochet de pédale, au moyen des propriétés ...

7.1.4
il est possible d'imprimer automatiquement une ligne reliant les notes = une ligne reliant les notes peut être imprimée automatiquement

Pourquoi revenir à la voix passive ?

en définissant comme vraie = "en positionnant à VRAI" ou "en attribuant la valeur VRAI" REMARQUE : VRAI est une valeur informatique booléenne opposée à FAUX, elle ne s'accorde ni en genre ni en nombre

En effet. À propos, quelle est la typographie appropriée pour ce "vrai" ?
« vrai » (entre guillemets)
/vrai/ (en italique)
Je préfère l'italique, mais est-ce correct ?

"en positionnant sur VRAI le commutateur"

Cela m'est apparu il y a peu, mais dans le cas présent, il ne s'agit plus vraiment de propriété, mais de "commutateur" puisqu'il ne peut prendre que la valeur Vrai ou Faux (Jour, Nuit a dit quelqu'un...).
Quant à la typographie, il faudrait consulter d'autres ouvrages pour dégager une tendance.

Je vais revoir l'ensemble à ce sujet après vos commentaires, car il y a plusieurs cas évidents.

Jean-Charles

···

Le vendredi 27 juillet 2007 à 21:08 +0200, P.E. Brame a écrit :

Tout à fait d'accord. C'est peut-être la préposition "de" dans "hampe
de la portée" qui gêne Pierre-Emmanuel, qui ici ne signifie pas
l'appartenance mais le lieu. Et si on utilisait "sur" ? "la hampe sur
l'une des deux portées", ça vous dit ? Pour info, l'original en anglais
utilise la préposition "in" ("dans").

John

···

Le lundi 30 juillet 2007 à 17:23 +0200, Jean-Charles Malahieude a écrit :

Le 30.07.2007 11:11, John Mandereau disait :
> Le vendredi 27 juillet 2007 à 21:08 +0200, P.E. Brame a écrit :
>> Bonjour à tous,

>
>> 7.1.5
>> On peut écrire des accords qui enjambent deux portées, en allongeant la
>> hampe de l'une des deux portées de façon à ce qu'elle rejoigne celle de
>> l'autre portée. = pour écrire des accords enjambant deux portées,
>> allongez la hampe des notes de l'une des deux portées pour qu'elle
>> rejoigne la hampe des notes l'autre portée
>
> ="Pour écrire des accords qui enjambent deux portées, on allonge la hampe
> de l'une des deux portées de façon à ce qu'elle rejoigne celle de
> l'autre portée."
>

En fait, j'ai une préférence pour la proposition originale de Valentin
et moi-même :
- Rien ne stipule que les hampes appartiennent à une porté ou l'autre.
   C'est juste là qu'elles se situent géographiquement.
- Nous utilisons un « pluriel générique » en parlant de hampe plutôt
   que de note : on peut avoir une hampe à 2 notes en clé de sol ET une
   hampe à 1 note seulement en clé de fa, mais ce n'est que le fait que
   les hampes soient reliées qui donnent l'indication au pianiste.

Le 30.07.2007 11:11, John Mandereau disait :

[...]

> ="Le contexte @internalsref{PianoStaff} est précisément
> conçu pour gérer la notation spécifique au piano, notamment ces croisements."
>
>

et pourquoi pas « notation spécifique aux claviers » ?

Bonne idée. J'ai depuis longtemps envie de renommer ou déplacer des
sections dans les chapitres 7 et 8, comme "Piano Music" -> "Keyboard
music" ; je soumettrai mes propositions à Graham (l'éditeur de la doc)
quand je trouverai enfin le temps :-p

[...]

>> et ce au moyen des propriétés |edge-width|, = en modifiant la valeur des
>> propriétés |edge-width|,
>
> Qu'apporte cette reformulation ?
>

Il est possible de d'affiner l'apparence d'un crochet de pédale, au
moyen des propriétés ...

Bien, cette reformulation est maintenant sur Git.

>> en définissant comme vraie = "en positionnant à VRAI" ou "en attribuant
>> la valeur VRAI"
>> REMARQUE : VRAI est une valeur informatique booléenne opposée à FAUX,
>> elle ne s'accorde ni en genre ni en nombre
>
> En effet. À propos, quelle est la typographie appropriée pour ce "vrai" ?
> « vrai » (entre guillemets)
> /vrai/ (en italique)
> Je préfère l'italique, mais est-ce correct ?
>

"en positionnant sur VRAI le commutateur"

Cela m'est apparu il y a peu, mais dans le cas présent, il ne s'agit
plus vraiment de propriété, mais de "commutateur" puisqu'il ne peut
prendre que la valeur Vrai ou Faux (Jour, Nuit a dit quelqu'un...).

C'est vrai que le terme "commutateur" est bien approprié, même si dans
ce cas le commutateur reste une propriété au sens des concepts internes
du programme LilyPond. Il me semble que nous devrions quand même garder
"propriété", pour familiariser le lecteur avec les concepts techniques
de LilyPond ; nous devrions éviter d'ajouter ou de masquer ces concepts
par du vocabulaire, ce qui pourrait apporter de la confusion chez le
lecteur. Qu'en pensent les utilisateurs pas toujours à l'aise avec les
contextes, propriétés, grobs, syntaxe Scheme et Cie ?

Quant à la typographie, il faudrait consulter d'autres ouvrages pour
dégager une tendance.

J'ai mis @emph{vrai} (pour mettre vrai en italique) partout ou j'ai
relu, on pourra toujours faire une substitution de texte sauvage si on
change d'avis.

Je vais revoir l'ensemble à ce sujet après vos commentaires, car il y
a plusieurs cas évidents.

Bonne relecture
John

···

Le lundi 30 juillet 2007 à 18:08 +0200, Jean-Charles Malahieude a écrit :

Le 31.07.2007 23:54, John Mandereau disait :

Le lundi 30 juillet 2007 à 18:08 +0200, Jean-Charles Malahieude a
écrit :

Le 30.07.2007 11:11, John Mandereau disait :

[...]

="Le contexte @internalsref{PianoStaff} est précisément
conçu pour gérer la notation spécifique au piano, notamment ces croisements."

et pourquoi pas « notation spécifique aux claviers » ?

Bonne idée. J'ai depuis longtemps envie de renommer ou déplacer des
sections dans les chapitres 7 et 8, comme "Piano Music" -> "Keyboard
music" ; je soumettrai mes propositions à Graham (l'éditeur de la doc)
quand je trouverai enfin le temps :-p

C'est vrai aussi que la harpe, bien qu'ayant plus de pédales que de touches, utilise aussi une double portée...

[...]

en définissant comme vraie = "en positionnant à VRAI" ou "en attribuant la valeur VRAI" REMARQUE : VRAI est une valeur informatique booléenne opposée à FAUX, elle ne s'accorde ni en genre ni en nombre

En effet. À propos, quelle est la typographie appropriée pour ce "vrai" ?
« vrai » (entre guillemets)
/vrai/ (en italique)
Je préfère l'italique, mais est-ce correct ?

"en positionnant sur VRAI le commutateur"

Cela m'est apparu il y a peu, mais dans le cas présent, il ne s'agit plus vraiment de propriété, mais de "commutateur" puisqu'il ne peut prendre que la valeur Vrai ou Faux (Jour, Nuit a dit quelqu'un...).

C'est vrai que le terme "commutateur" est bien approprié, même si dans
ce cas le commutateur reste une propriété au sens des concepts internes
du programme LilyPond. Il me semble que nous devrions quand même garder
"propriété", pour familiariser le lecteur avec les concepts techniques
de LilyPond ; nous devrions éviter d'ajouter ou de masquer ces concepts
par du vocabulaire, ce qui pourrait apporter de la confusion chez le
lecteur. Qu'en pensent les utilisateurs pas toujours à l'aise avec les
contextes, propriétés, grobs, syntaxe Scheme et Cie ?

Cela m'est en fait venu à la lecture de "Latex pour l'impatient" qui m'a bien débroussaillé ma compréhension de LaTeX, et où les auteurs parlent souvent de commutateur pour ces pseudo-macros qui se fixent en une fois, et de bascule dans les cas cela est temporaire (type @code{\melisma} ... @code{\melismaEnd}. Je me rends compte que ces formulations sont parfois plus pertinentes quand on en vient à considérer la propriété d'une propriété... dans les chapitre 8.

Quant à la typographie, il faudrait consulter d'autres ouvrages pour dégager une tendance.

J'ai mis @emph{vrai} (pour mettre vrai en italique) partout ou j'ai
relu, on pourra toujours faire une substitution de texte sauvage si on
change d'avis.

OK. Cela peut permettre à la longue de faire l'association avec "true".

@+
Jean-Charles

Je partage cette opinion. Je crios qu'il faut absolument garder le
terme de "propriété". J'ai d'ailleurs moi-même galéré, pour cette
même raison, avec l'expression "knobs and switches" dans
changing-defaults.

Par ailleurs, je ne suis pas d'accord pour considérer le "vrai" comme
un opérateur booléen dans ce cas ; ce n'est pas parce que l'adjectif
ne s'accorde pas en anglais que nous devons répercuter cette syntaxe
dans de la documentation française ; ça serait valable si on pouvait
écrire ##V au lieu de ##T pour true, mais dans la mesure où ce n'est
pas le cas, nous n'avons pas ici affaire à du code, mais à une
explication en bon français. Par contre, il vaut mieux mettre
systématiquement un @example à la suite, pour tout clarifier.

Pour toutes ces raisons, je persiste avec ma formulation d'origine :

en définissant comme vraie (lettre "t" pour @emph{true} en anglais) la
propriété tagada dans le contexte TsoinTsoin :
@example
\set TsoinTsoin.tagada = ##t
@end example

Qu'en dites-vous ?
V.

···

Le 31/07/07, John Mandereau<****@****> a écrit :

> >> en définissant comme vraie = "en positionnant à VRAI" ou "en attribuant
> >> la valeur VRAI"
> >> REMARQUE : VRAI est une valeur informatique booléenne opposée à FAUX,
> >> elle ne s'accorde ni en genre ni en nombre
> "en positionnant sur VRAI le commutateur"
>
> Cela m'est apparu il y a peu, mais dans le cas présent, il ne s'agit
> plus vraiment de propriété, mais de "commutateur" puisqu'il ne peut
> prendre que la valeur Vrai ou Faux (Jour, Nuit a dit quelqu'un...).

C'est vrai que le terme "commutateur" est bien approprié, même si dans
ce cas le commutateur reste une propriété au sens des concepts internes
du programme LilyPond. Il me semble que nous devrions quand même garder
"propriété", pour familiariser le lecteur avec les concepts techniques
de LilyPond ; nous devrions éviter d'ajouter ou de masquer ces concepts
par du vocabulaire, ce qui pourrait apporter de la confusion chez le
lecteur. Qu'en pensent les utilisateurs pas toujours à l'aise avec les
contextes, propriétés, grobs, syntaxe Scheme et Cie ?

> > >> en définissant comme vraie = "en positionnant à VRAI" ou "en attribuant
> > >> la valeur VRAI"
> > >> REMARQUE : VRAI est une valeur informatique booléenne opposée à FAUX,
> > >> elle ne s'accorde ni en genre ni en nombre
> > "en positionnant sur VRAI le commutateur"
> >
> > Cela m'est apparu il y a peu, mais dans le cas présent, il ne s'agit
> > plus vraiment de propriété, mais de "commutateur" puisqu'il ne peut
> > prendre que la valeur Vrai ou Faux (Jour, Nuit a dit quelqu'un...).
>
> C'est vrai que le terme "commutateur" est bien approprié, même si dans
> ce cas le commutateur reste une propriété au sens des concepts internes
> du programme LilyPond. Il me semble que nous devrions quand même garder
> "propriété", pour familiariser le lecteur avec les concepts techniques
> de LilyPond ; nous devrions éviter d'ajouter ou de masquer ces concepts
> par du vocabulaire, ce qui pourrait apporter de la confusion chez le
> lecteur. Qu'en pensent les utilisateurs pas toujours à l'aise avec les
> contextes, propriétés, grobs, syntaxe Scheme et Cie ?

Je partage cette opinion. Je crios qu'il faut absolument garder le
terme de "propriété". J'ai d'ailleurs moi-même galéré, pour cette
même raison, avec l'expression "knobs and switches" dans
changing-defaults.

Par ailleurs, je ne suis pas d'accord pour considérer le "vrai" comme
un opérateur booléen dans ce cas ;

  __valeur___ booléenne

ce n'est pas parce que l'adjectif
ne s'accorde pas en anglais que nous devons répercuter cette syntaxe
dans de la documentation française ; ça serait valable si on pouvait
écrire ##V au lieu de ##T pour true, mais dans la mesure où ce n'est
pas le cas, nous n'avons pas ici affaire à du code, mais à une
explication en bon français.

La valeur d'une variable informatique (une propriété de LilyPond dans
notre cas) est invariable ; c'est vrai pour les nombres, les couleurs,
les booléens, et en général tout adjectif ou déterminant utilisé comme
valeur d'une variable. C'est cette règle qui explique pourquoi les
phrases suivantes sont incorrectes :

"On attribue la valeur /bleue/ à la variable Couleur."
"On attribue la valeur /une/ à la variable NombreDeTapis."

Par contre, il vaut mieux mettre
systématiquement un @example à la suite, pour tout clarifier.

D'accord -- je crois que c'est déjà le cas dans le manuel en anglais.

Pour toutes ces raisons, je persiste avec ma formulation d'origine :

en définissant comme vraie (lettre "t" pour @emph{true} en anglais) la
propriété tagada dans le contexte TsoinTsoin :
@example
\set TsoinTsoin.tagada = ##t
@end example

Il me semble qu'on peut "La propriété tagada est vraie." pour faire plus
court que "La propriété tagada a pour valeur /vrai/", mais c'est
peut-être un peu moins clair. La reformulation que j'ai appliquée dans
basic-notation est

"Il faut/On peut définir à @emph{vrai} (@q{t} pour @q{true}) la
propriété @code{toto}."

John

···

Le mercredi 01 août 2007 à 10:56 +0200, Valentin Villenave a écrit :

Le 31/07/07, John Mandereau<****@****> a écrit :

"On attribue la valeur /bleue/ à la variable Couleur."
"On attribue la valeur /une/ à la variable NombreDeTapis."

Oui ; c'est pourquoi mon propos est justement d'éviter l'emploi du
terme "valeur", ou toute autre construction conceptuelle. Il me paraît
plus simple de dire "la propriété est vraie" que "la propriété a pour
valeur vrai" ou "la propriété est définie sur vrai" -- dernière phrase
particulièrement hideuse :slight_smile:

C'est la raison de mon "définie comme vraie", ça me paraît une
construction plus française ; et ça me permettait d'employer ici
"vrai" comme adjectif.

Il me semble qu'on peut "La propriété tagada est vraie." pour faire plus
court que "La propriété tagada a pour valeur /vrai/", mais c'est
peut-être un peu moins clair.

Au contraire, ça ma paraîtrait plus clair car plus simple, plus
lisible pour un non-initié.

"Il faut/On peut définir à @emph{vrai} (@q{t} pour @q{true}) la
propriété @code{toto}."

Définir à "vrai" ? ça fait un peu moche non ? (ou c'est moi ?)

De toute façon, je crois qu'il faudra refaire (même dans la doc
originale) une mise au point très claire quant aux définitions des
propriétés, les contextes, les variables booléenes, l'emploi des #
avant les valeurs, etc. C'est brièvement évoqué dans putting, puis
plus en détail dans changing-defaults, mais ça manque de clarté et
d'accessibilité pour les néophytes. Peut-être faudrait-il, par
exemple, insérer un aide-mémoire au début de tweaking ?

V. Villenave

···

Le 01/08/07, John Mandereau<****@****> a écrit :

> "On attribue la valeur /bleue/ à la variable Couleur."
> "On attribue la valeur /une/ à la variable NombreDeTapis."

Oui ; c'est pourquoi mon propos est justement d'éviter l'emploi du
terme "valeur", ou toute autre construction conceptuelle. Il me paraît
plus simple de dire "la propriété est vraie" que "la propriété a pour
valeur vrai"

C'est plus simple, mais cela cache la distance qu'il y a entre la pensée
de l'utilisateur en français et la construction informatique
conceptuelle.

ou "la propriété est définie sur vrai" -- dernière phrase
particulièrement hideuse :slight_smile:

En effet.

> "Il faut/On peut définir à @emph{vrai} (@q{t} pour @q{true}) la
> propriété @code{toto}."

Définir à "vrai" ? ça fait un peu moche non ? (ou c'est moi ?)

C'est moche, je n'avais rien trouvé de mieux :frowning:
Et que dites-vous de

"On règle à/sur vrai la propriété bidule"

?

La traduction de "set /var/ to /value/" apparaît vraiment comme une
prise de tête. Je propose de poser la question sur la liste d'une
grande équipe de traducteurs francophones ****@**** (vous pouvez
éventuellement vous abonner sur http://traduc.org -- le trafic de cette
liste n'est pas trop élevé). Je ne préfère pas poser la question
moi-même car je pars demain soir et ne reviens que 18 août (je n'aurais
aucun accès Internet).

De toute façon, je crois qu'il faudra refaire (même dans la doc
originale) une mise au point très claire quant aux définitions des
propriétés, les contextes, les variables booléenes, l'emploi des #
avant les valeurs, etc.

D'accord. Je suis sûr que des utilisateurs pourront apporter leur
expérience pour cette refonte non triviale.

C'est brièvement évoqué dans putting, puis
plus en détail dans changing-defaults, mais ça manque de clarté et
d'accessibilité pour les néophytes. Peut-être faudrait-il, par
exemple, insérer un aide-mémoire au début de tweaking ?

Quel genre d'aide-mémoire ? On peut aussi mettre une référence vers une
section où tout est bien expliqué.

John

···

Le mercredi 01 août 2007 à 12:26 +0200, Valentin Villenave a écrit :

Le 01/08/07, John Mandereau<****@****> a écrit :

"On règle à/sur vrai la propriété bidule"

Les quelques rares livres de programation en français que j'ai pu lire utilisait la formulation suivante :

"assigner à la la propriété P la valeur V"

Ce qui donnerait dans ce cas.

"On assigne à la propriété bidule la valeur vrai."

Mais bon dans la formulation précédente, on comprend très bien aussi.

Gilles.

Je trouve ça beaucoup élégant (et plus proche de la syntaxe lilypond)
de commencer ainsi par évoquer la propriété, *puis* d'indiquer la
valeur.

Comment se fait-il qu'on n'y ait pas pensé plus tôt ? :slight_smile:

V.V.

···

Le 02/08/07, Gilles THIBAULT<****@****> a écrit :

"On assigne à la propriété bidule la valeur vrai."

:-p

J'espère que nous sommes tous d'accord pour adopter cette formulation.
Je pars ce soir, donc j'ai pas le temps de m'en occuper, mais vous
pourrez toujours le faire avant mon retour le 13 août :wink:

Par ailleurs, le "committish" de instrument-notation indique que ce
fichier est à jour, ce qui se révèle faux à la suite d'une erreur de
compilation (la macro @inputfileref n'existe plus) : il est important
que nous le mettions à jour en relisant tout le document par rapport au
texte en anglais, avant de le mettre sur la branche master.

Dans quelques heures la dernière révision de la doc d'après les sources
de la branche lilypond/translation sera sur
http://john.mandereau.free.fr/lilypond-doc/index.fr.html

À bientôt
John

···

Le vendredi 03 août 2007 à 00:01 +0200, Valentin Villenave a écrit :

Le 02/08/07, Gilles THIBAULT<****@****> a écrit :

> "On assigne à la propriété bidule la valeur vrai."

Je trouve ça beaucoup élégant (et plus proche de la syntaxe lilypond)
de commencer ainsi par évoquer la propriété, *puis* d'indiquer la
valeur.

Comment se fait-il qu'on n'y ait pas pensé plus tôt ? :slight_smile:

Le 03.08.2007 14:51, John Mandereau disait :

"On assigne à la propriété bidule la valeur vrai."

Je trouve ça beaucoup élégant (et plus proche de la syntaxe lilypond)
de commencer ainsi par évoquer la propriété, *puis* d'indiquer la
valeur.

Comment se fait-il qu'on n'y ait pas pensé plus tôt ? :slight_smile:

:-p

J'espère que nous sommes tous d'accord pour adopter cette formulation.
Je pars ce soir, donc j'ai pas le temps de m'en occuper, mais vous
pourrez toujours le faire avant mon retour le 13 août :wink:

OK pour moi. Je m'en occupe, pour laisser du temps à Valentin pour son opéra.

Je vais aussi tout relire tranquillement et avec attention : j'ai vu trainer une « clé de sa »...

Par ailleurs, le "committish" de instrument-notation indique que ce
fichier est à jour, ce qui se révèle faux à la suite d'une erreur de
compilation (la macro @inputfileref n'existe plus) : il est important
que nous le mettions à jour en relisant tout le document par rapport au
texte en anglais, avant de le mettre sur la branche master.

L 646 : @inputfileref{input/@/test,chord@/-names@/-jazz@/.ly}

    ==> @lsr{chords,chord-names-jazz.ly}

L 671 : @lsr{chords/,chord@/-name@/-exceptions@/.ly},
@lsr{chords,chord@/-name@/-major7@/.ly} et
@inputfileref{input/@/test,chord@/-names@/-jazz@/.ly}.

    ==> @lsrdir{chords}

L2408 : @inputfileref{input/@/test,fret@/-diagram@/.ly}

    ==> @lsrdir{guitar}

L2784 : @inputfileref{input/@/test,ancient@/-accidentals@/.ly}.

    ==> @lsr{ancient,ancient-accidentals.ly}.

L2798 : @inputfileref{input/@/test,ancient@/-accidentals@/.ly}.

    ==> @lsrdir{ancient}

L2826 : @inputfileref{input/@/test,rests@/.ly}.

    ==> @lsr{pitches,rests}.

L3391 : @inputfileref{input/@/test,divisiones@/.ly}

    ==> @lsr{expressive,breathing-sign.ly}

C'est la quatrième fois que je tente d'arriver au bout depuis hier après midi. Peut-être cela y contribuait-il ? Les dernières lignes du log demandaient Hercule Poirot et ce n'est pas moi :

************ Ligne 112766 **********************
) [219] [220] [221]) (./fdl.pdftexi Annexe F [222] [223] [224] [225] [226]
[227]) Annexe G [228] Annexe H [229] [230] )
(see the transcript file for additional information){/usr/share/texmf/fonts/enc
/dvips/cm-super/cm-super-t1.enc}</usr/share/texmf/fonts/type1/bluesky/cm/cmb10.

</usr/share/texmf/fonts/type1/bluesky/cm/cmbx12.pfb></usr/share/texmf/fonts

/type1/bluesky/cm/cmcsc10.pfb></usr/share/texmf/fonts/type1/bluesky/cm/cmr10.pf

</usr/share/texmf/fonts/type1/bluesky/cm/cmr7.pfb></usr/share/texmf/fonts/typ

e1/bluesky/cm/cmr8.pfb></usr/share/texmf/fonts/type1/bluesky/cm/cmr9.pfb></usr/
share/texmf/fonts/type1/bluesky/cm/cmsl10.pfb></usr/share/texmf/fonts/type1/blu
esky/cm/cmsltt10.pfb></usr/share/texmf/fonts/type1/bluesky/cm/cmsy10.pfb></usr/
share/texmf/fonts/type1/bluesky/cm/cmsy9.pfb></usr/share/texmf/fonts/type1/blue
sky/cm/cmti10.pfb></usr/share/texmf/fonts/type1/bluesky/cm/cmti9.pfb></usr/shar
e/texmf/fonts/type1/bluesky/cm/cmtt10.pfb></usr/share/texmf/fonts/type1/bluesky
/cm/cmtt12.pfb></usr/share/texmf/fonts/type1/bluesky/cm/cmtt9.pfb></usr/share/t
exmf/fonts/type1/public/cm-super/sfrm0900.pfb></usr/share/texmf/fonts/type1/pub
lic/cm-super/sfrm1095.pfb></usr/share/texmf/fonts/type1/urw/ncntrsbk/uncb8a.pfb
></usr/share/texmf/fonts/type1/urw/ncntrsbk/uncbi8a.pfb></usr/share/texmf/fonts
/type1/urw/ncntrsbk/uncr8a.pfb></usr/share/texmf/fonts/type1/urw/ncntrsbk/uncri
8a.pfb></usr/share/texmf/fonts/type1/urw/times/utmr8a.pfb>
Output written on lilypond.pdf (232 pages, 7118282 bytes).
Transcript written on lilypond.log.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
make[4]: *** [out-www/lilypond.pdf] Erreur 1
rm out-www/lilypond.nexi out-www/lilypond-program.texi out-www/lilypond.texi out-www/lilypond-program.nexi
make[4]: quittant le répertoire « /home/jcharles/GIT/Fabrik/Documentation/fr/user »
make[3]: *** [WWW] Erreur 2
make[3]: quittant le répertoire « /home/jcharles/GIT/Fabrik/Documentation/fr »
make[2]: *** [WWW] Erreur 2
make[2]: quittant le répertoire « /home/jcharles/GIT/Fabrik/Documentation »
make[1]: *** [WWW] Erreur 2
make[1]: quittant le répertoire « /home/jcharles/GIT/Fabrik »
make: *** [web] Erreur 2

Compilation exited abnormally with code 2 at Fri Aug 3 15:07:02

···

Le vendredi 03 août 2007 à 00:01 +0200, Valentin Villenave a écrit :

Le 02/08/07, Gilles THIBAULT<****@****> a écrit :

*************************************************

John, il faudra aussi tenir compte du nouveau découpage chez lez hispaniques et les teutonnants (liens brisés)...

Dans quelques heures la dernière révision de la doc d'après les sources
de la branche lilypond/translation sera sur
http://john.mandereau.free.fr/lilypond-doc/index.fr.html

Et après, tu auras des mollets en béton armé...

@+

OK pour moi. Je m'en occupe, pour laisser du temps à Valentin pour son
opéra.

Merci pour ta prévenance ; je vais quand même tâcher de touver un
moment pour bosser sur changing-defaults (il me semble que j'avais
aussi une relecture en souffrance, faut que je retrouve où).

Je vais aussi tout relire tranquillement et avec attention : j'ai vu
trainer une « clé de sa »...

Bin quoi, c'est pas celle-là qui sert à transposer la clé de dol ?
:smiley:

/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.

Je n'y connais pas plus que toi (euphemism inside), mais as-tu vérifié
s'il n'y a pas de problème avec ton installation de tex ?

(juste au pif...)

Bonnes vacances à toi John :slight_smile:

Cordialement,
V.V.

···

Le 03/08/07, Jean-Charles Malahieude<****@****> a écrit :

Le 03.08.2007 18:18, Valentin Villenave disait :

OK pour moi. Je m'en occupe, pour laisser du temps à Valentin pour son
opéra.

Merci pour ta prévenance ; je vais quand même tâcher de touver un
moment pour bosser sur changing-defaults (il me semble que j'avais
aussi une relecture en souffrance, faut que je retrouve où).

Je vais aussi tout relire tranquillement et avec attention : j'ai vu
trainer une « clé de sa »...

Bin quoi, c'est pas celle-là qui sert à transposer la clé de dol ?
:smiley:

et vérifier que les liens ouvrent bien ce qu'il faut...

/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.

Je n'y connais pas plus que toi (euphemism inside), mais as-tu vérifié
s'il n'y a pas de problème avec ton installation de tex ?

(juste au pif...)

Sortez le mouchoir...

Après synchronisation avec ce que John a transmis sur git en début d'après-midi, et une bonne demie heure de chauffe intense :

make[2]: quittant le répertoire /home/jcharles/GIT/Fabrik/Documentation
make[1]: quittant le répertoire /home/jcharles/GIT/Fabrik

Compilation finished at Fri Aug 3 19:09:52

Rest' pu qu'à s'y r'mett

@+
Jean-Charles

···

Le 03/08/07, Jean-Charles Malahieude<****@****> a écrit :