@c -*- coding: utf-8; mode: texinfo; documentlanguage: fr -*-
@c This file is part of lilypond.tely
@ignore
- Translation of GIT committish: ef2a56348261c657e63bfea9341bfe8e2a22f486
+ Translation of GIT committish: 964d024dd4f022ba7cd66adc13c0169035d4c4e5
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
l'utiliser avec une version plus récente de LilyPond ? La syntaxe du
langage d'entrée change parfois lorsque LilyPond s'améliore. La
plupart des changements peuvent être appliqués automatiquement avec
-@code{convert-ly}, mais quelques-uns peuvent demander une intervention
+@code{convert-ly}, mais quelques-uns peuvent requérir une intervention
manuelle. Vos fichiers LilyPond peuvent être structurés de manière à
faciliter leur mise à jour.
@end itemize
même pour de petits fichiers. Par expérience, il est très difficile
de se rappeler quelle version de LilyPond on utilisait quelques
années auparavant. L'utilitaire @code{convert-ly} demande que vous
-spécifiiez quelle version de LilyPond vous utilisiez.
+spécifiiez la version de LilyPond vous utilisiez alors.
@item @strong{Ajoutez des contrôles}: @ref{Bar check}, @ref{Octave
check} et @ref{Barnumber check}. Si vous avez ajouté des contrôles de
compilation --- voir @ref{Skipping corrected music} ;
@item définissez @code{mBreak = @{\break @}} et insérez
-@code{\mBreak} dans le fichier d'entrée des sauts de ligne identiques à la
-partition originale. Cela facilite la comparaison entre la partition
-originale et la partition de LilyPond. Lorsque vous avez fini de
-relire votre musique, vous pouvez définir @code{mBreak = @{ @}} pour
-enlever tous ces sauts de ligne, et laisser LilyPond placer les sauts
-de ligne selon son propre algorithme.
+@code{\mBreak} dans le fichier d'entrée pour obtenir des sauts de
+ligne identiques à la partition originale. Cela facilite la
+comparaison entre la partition originale et la partition de
+LilyPond. Lorsque vous avez fini de relire votre musique, vous pouvez
+définir @code{mBreak = @{ @}} pour enlever tous ces sauts de ligne, et
+laisser LilyPond placer les sauts de ligne selon son propre algorithme.
@end itemize
@itemize @bullet
-@item @strong{utilisez un identificateur pour chaque voix},
+@item @strong{Utilisez un identificateur pour chaque voix},
avec un minimum de structure dans la définition. La structure de la
section @code{\score} est la plus susceptible de changer, notamment
dans une nouvelle version de LilyPond, alors que la définition du
@item @strong{Séparez les retouches} des définitions de
musique. Ce conseil a été vu dans @ref{General suggestions},
-mais pour les gros projets c'est absolument vital. Nous
+mais pour les projets d'importance c'est absolument vital. Nous
pouvons avoir besoin de changer la définition de
@code{fthenp}, mais dans ce cas nous n'aurons besoin de le faire
qu'une seule fois, et nous pourrons encore éviter de
Jusqu'ici nous avons vu des substitutions statiques : quand LilyPond
rencontre @code{\padText}, il le remplace par le contenu que nous lui
-avons défini --- c'est-à-dire le contenu à droite de @code{padText=}).
+avons défini --- c'est-à-dire le contenu à droite de @code{padText=}.
LilyPond gère également des substitutions non-statiques --- vous
pouvez les voir comme des fonctions.
Il y a quelques problèmes de chevauchement ; nous allons arranger
cela en utilisant les techniques de @ref{Moving objects}. On peut
-aussi aussi faire quelque chose pour les définitions de @code{mpdolce}
+aussi faire quelque chose pour les définitions de @code{mpdolce}
et @code{tempoMark}. Elles produisent le résultat que nous désirons,
mais nous pourrions aussi vouloir les utiliser dans une autre pièce.
Il suffirait de les copier et les coller au début de chaque
@end example
Cette approche peut être utile même si vous ne produisez qu'un seul
-jeu de partitions. J'utilise une demi-douzaine de fichiers de
-@qq{feuille de style} pour mes projets. Je commence chaque fichier de
-musique par @code{\include "../global.ly"} qui contient :
+jeu de partitions. J'utilise personnellement une demi-douzaine de
+fichiers de @qq{feuille de style} pour mes projets. Je commence
+chaque fichier de musique par @code{\include "../global.ly"} qui contient :
@example
%%% global.ly
LilyPond est fourni avec un utilitaire qui facilite cette mise à
jour : @code{convert-ly}. Pour savoir comment utiliser ce programme,
-voir @ref{Updating files with convert-ly}.
+voir @rprogram{Updating files with convert-ly}.
Malheureusement, @code{convert-ly} ne peut pas réaliser toutes les
modifications. Il s'occupe des changements qui ne requièrent qu'une
simple substitution de texte --- comme @code{raggedright} devenant
@code{ragged-right} ---, les autres étant trop compliqués à effectuer.
Les changements de syntaxe qui ne sont pas gérés par @code{convert-ly}
-sont énumérés dans @ref{Updating files with convert-ly}.
+sont énumérés dans @rprogram{Updating files with convert-ly}.
Par exemple, dans les versions 2.4 et antérieures de LilyPond,
les accents et les lettres non anglaises étaient entrées en
@section Minimal examples
Un exemple minimal est un exemple de code aussi court que possible.
-De tels exemples sont bien plus compréhensibles que des exemple
+De tels exemples sont bien plus compréhensibles que des exemples
longs. Les exemples minimaux sont utilisés pour
@itemize
Tout l'intérêt d'un exemple minimal réside dans sa facilité de lecture :
@itemize
@item évitez d'utiliser des notes, armures ou métriques compliquées, à
-moins que vous vouliez montrer quelque chose en rapport avec
+moins que vous ne vouliez montrer quelque chose en rapport avec
celles-ci,
@item n'utilisez pas de commandes @code{\override} sauf si elles font
l'intérêt de l'exemple.
projects / lilypond.git / blobdiff