@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: bfbaf6488d99ab4cdfcb4efdc67eaca63a636106
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
@end ignore
+@c Translators: Ludovic Sardain
+@c Translation checkers: Jean-Yves Baudais, Valentin Villenave, John Mandereau, Jean-Charles Malahieude
+
@node Working on LilyPond projects
@chapter Working on LilyPond projects
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
Voici quelques conseils qui peuvent vous éviter certains problèmes ou
en résoudre d'autres.
-@itemize @bullet
+@itemize
@item @strong{Ajoutez le numéro de version dans chaque fichier}.
Notez que chaque fichier modèle contient une ligne @code{\version
-"2.11.15"}. Nous vous conseillons fortement d'inclure cette ligne,
+"2.11.32"}. Nous vous conseillons fortement d'inclure cette ligne,
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.
+années auparavant. L'utilitaire @command{convert-ly} demande que vous
+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
+@item @strong{Ajoutez des contrôles}: @ruser{Bar check}, @ruser{Octave
+check} et @ruser{Barnumber check}. Si vous avez ajouté des contrôles de
loin en loin, et que vous faites une erreur, vous pourrez la retrouver
plus rapidement. @qq{De loin en loin}, qu'est-ce à dire ? Cela
dépend de la complexité de la musique. Pour de la musique très
viennent d'un défaut de parité entre @code{@{} et @code{@}}.
@item @strong{Séparez les affinages de mise en forme} de la musique
-elle-même. Voyez @ref{Saving typing with identifiers and functions} et
-@ref{Style sheets}.
+elle-même. Voyez @ruser{Saving typing with identifiers and functions} et
+@ruser{Style sheets}.
@end itemize
à la fois --- mais toujours une seule mesure par ligne de texte ---,
et vérifiez chaque système lorsqu'il est terminé. Vous pouvez
utiliser la commande @code{showLastLength} pour accélérer la
-compilation --- voir @ref{Skipping corrected music} ;
+compilation --- voir @ruser{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
@end example
@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
+musique. Ce conseil a été vu dans @ruser{General suggestions},
+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
@lilypond[quote,verbatim,ragged-right]
hornNotes = \relative c'' { c4 b dis c }
\score {
- {
- \hornNotes
- }
+ {
+ \hornNotes
+ }
}
@end lilypond
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.
@lilypond[quote,verbatim,ragged-right]
+padText =
#(define-music-function (parser location padding) (number?)
#{
\once \override TextScript #'padding = #$padding
Utiliser les identificateurs est aussi un bon moyen pour vous épargner
du travail si la syntaxe de LilyPond change un jour --- voir
-@ref{Updating old files}. Si vous avez une seule définition, par
-exemple @code{\dolce}, pour tous vos fichiers (voir @ref{Style
+@ruser{Updating old files}. Si vous avez une seule définition, par
+exemple @code{\dolce}, pour tous vos fichiers (voir @ruser{Style
sheets}), et que la syntaxe change, alors vous n'aurez qu'à mettre à
jour votre seule définition @code{\dolce}, au lieu de devoir modifier
chaque fichier @code{.ly}.
@section Style sheets
La sortie que produit LilyPond peut être largement modifiée --- voir
-@ref{Tweaking output} pour plus de détails. Mais que faire si vous
+@ruser{Tweaking output} pour plus de détails. Mais que faire si vous
avez beaucoup de fichiers auxquels vous souhaitez appliquer vos
retouches ? Ou si vous souhaitez simplement séparer les retouches de
la musique elle-même ? Rien de plus facile.
Prenons un exemple. Ne vous inquiétez pas si vous ne comprenez pas
les parties avec tous les @code{#()}. Celles-ci sont expliquées dans
-@ref{Advanced tweaks with Scheme}.
+@ruser{Advanced tweaks with Scheme}.
@lilypond[quote,verbatim,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
@end lilypond
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}
+cela en utilisant les techniques de @ruser{Moving objects}. On peut
+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
-\version "2.11.15"
+\version @w{"@version{}"}
#(ly:set-option 'point-and-click #f)
\include "../init/init-defs.ly"
\include "../init/init-mise-en-page.ly"
fonctionnalités.
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}.
+jour : @command{convert-ly}. Pour savoir comment utiliser ce programme,
+voir @rprogram{Updating files with convert-ly}.
-Malheureusement, @code{convert-ly} ne peut pas réaliser toutes les
+Malheureusement, @command{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}.
+Les changements de syntaxe qui ne sont pas gérés par @command{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
Une autre technique de déboguage très utile est la construction
@iftex
-de @ref{Minimal examples}.
+de @ruser{Minimal examples}.
@end iftex
@ifnottex
-d'@ref{Minimal examples}.
+d'@ruser{Minimal examples}.
@end ifnottex
@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.