lilypond-user-fr
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Mandereau
Subject: Re: remarques de traduction : chapitre 7 "Notation spécifique" du manuel
Date: Wed, 01 Aug 2007 11:45:04 +0200

Le mercredi 01 août 2007 à 10:56 +0200, Valentin Villenave a écrit :
> Le 31/07/07, John Mandereau<address@hidden> 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 ?
> 
> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]