Re: traduction de "working"

[Jean-Charles]

Le 23.01.2007 16:52, Ludovic Sardain disait :
> Bonjour à tous,
>
> je viens de finir le premier jet de la traudction du fichier 
> "working.itely".
>
> Je vous la livre en pièce jointe pour relecture. Veuillez s'il vous
> plaît faire vos corrections directement sur le fichier et le renvoyer,
> ou encore mieux, donner le résultat de la commande diff -u
> ancienfichier fichiercorrigé

Bonsoir,
Ci-joint un différentiel sur le fichier de Valentin.

Une phrase, ligne 35, ne me plaît cependant pas vraiment.


« Cependant, il y a quelques considérations à prendre
en compte lorsque l'on écrit un fichier LilyPond. »


Je comprends à  la lecture de la version originale
« However, there are a few other things to consider when writing 
lilypond files. » qu'il est bon d'adopter certaines pratiques lorsque 
l'on écrit des fichiers LilyPond. Je n'ai pas trouvé de traduction 
élégante pour retranscrire ce conseil-truc-habitude-à-prendre;

@+
Jean-Charles

--- working.itely.orig  2007-01-23 19:22:50.000000000 +0100
+++ working.itely.new   2007-01-23 20:55:58.000000000 +0100
@@ -28,28 +28,26 @@
 
 Maintenant vous êtes prêts à travailler avec de plus gros fichiers
 LilyPond -- des pièces entières, et plus seulement les petits
-exemples du tutoriel.  Mais comment devriez-vous commencer à faire
-cela?
+exemples du tutoriel.  Mais par où commencer, direz-vous ?
 
 Tant que LilyPond peut comprendre vos fichiers et produire la
 sortie que vous souhaitez, l'organisation du code n'a pas
-d'importance.  Cependant, il y a quelques considérations à prendre
+d'importance. Cependant, il y a quelques considérations à prendre
 en compte lorsque l'on écrit un fichier LilyPond.
 
 @itemize @bullet
address@hidden Si vous faites une erreur, la structure du fichier LilyPond
address@hidden Si vous faites une erreur, la structure même du fichier LilyPond
 peut permettre de la trouver plus ou moins facilement.
 
 @item Et si vous souhaitez partager vos fichiers avec quelqu'un
 d'autre, ou si vous souhaitez modifier vos propres fichiers dans
-quelques années?  Certains fichiers LilyPond sont compréhensibles
-au premier coup d'oeil.  D'autres peuvent vous donner un mal de
-crâne pendant une heure.
+quelques années ? Certains fichiers LilyPond sont compréhensibles
+au premier coup d'oeil. D'autres peuvent devenir source de migraine.
 
 @item Et si vous souhaitez mettre à jour votre fichier pour
-l'utiliser avec une version plus récente de LilyPond?  La syntaxe
+l'utiliser avec une version plus récente de LilyPond ? La syntaxe
 du langage d'entrée change quelques fois lorsque LilyPond
-s'améliore.  La plupart des modification peuvent être faites
+s'améliore. La plupart des modification peuvent être faites
 automatiquement avec @code{convert-ly}, mais quelques-unes
 peuvent demander une intervention manuelle. Les fichier LilyPond
 peuvent être structurés de manière à être plus faciles à mettre
@@ -70,36 +68,36 @@
 @item @strong{ajoutez les numéros de version dans chaque fichier}. 
 Notez que chaque fichier modèle contient un ligne @code{\version
 "2.9.13"}.  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 vous utilisiez quelques années auparavant. 
 L'utilitaire @code{convert-ly} demande que vous spécifiiez quelle version de 
LilyPond vous avez utilisé.
+même pour de petits fichiers. Par expérience, il est très difficile de se 
rappeler quelle version de LilyPond vous utilisiez quelques années auparavant. 
 L'utilitaire @code{convert-ly} demande que vous spécifiiez quelle version de 
LilyPond vous avez utilisé.
 
 @item @strong{ajoutez des contrôles}: @ref{Bar check} et 
 @ref{Octave check}.  Si vous avez ajouté des contrôles
 régulièrement, et que vous faites une erreur, vous pourrez la
-retrouver plus rapidement.  A quelle fréquence faut-il en ajouter? 
-Cela dépends de la complexité de la musique.  Pour de la musique
+retrouver plus rapidement. À quelle fréquence faut-il en ajouter? 
+Cela dépend de la complexité de la musique. Pour de la musique
 très simple, peut-être une ou deux fois. Pour de la musique plus
 complexe, peut-être à chaque mesure.
 
address@hidden @strong{Une mesure par ligne de texte}.  S'il y a quelque 
address@hidden @strong{Une mesure par ligne de texte}. S'il y a quelque 
 chose de compliqué, soit dans la musique en elle-même, soit dans
 le résultat que vous désirez, il est souvent bon de n'écrire
-qu'une seule mesure par ligne.  La place économisée en tassant
+qu'une seule mesure par ligne. La place économisée en tassant
 huit mesures par ligne n'a que peu de valeur si vous devez
 corriger vos fichiers.
 
address@hidden @strong{Commentez vos fichiers}.  Utilisez soit des
address@hidden @strong{Commentez vos fichiers}. Utilisez soit des
 numéros de mesure (assez souvent), soit des références au contenu
 musical (@q{second thème des violons,} @q{quatrième variation,}
-etc.).  Vous pouvez ne pas avoir besoin des commentaires lorsque
+etc.). Vous pouvez ne pas avoir besoin des commentaires lorsque
 vous écrivez une pièce pour la première fois, mais si vous
-souhaitez y revenir deux ou trois années plus tard pour changer
+souhaitez y revenir deux ou trois ans plus tard pour changer
 quelque chose, ou si vous donnez le fichier source à un ami, ce
 sera beaucoup plus difficile de déterminer vos intentions ou 
 la manière dont votre fichier est structuré si vous ne l'avez
 pas commenté.
 
address@hidden @strong{Indentez vos crochets}.  Beaucoup de problèmes
-viennent de la différence de nombre de @address@hidden et de @address@hidden
address@hidden @strong{Indentez vos crochets}. Beaucoup de problèmes
+viennent d'un défaut de parité entre @address@hidden et @address@hidden
 
 @item @strong{Séparez les modifications} des définitions de
 musique.  Voyez @ref{Saving typing with identifiers and
@@ -117,7 +115,7 @@
 @itemize @bullet
 
 @item N'entrez qu'un seul système de la partition originale
-Ã  la fois (mais toujours qu'une seule mesure par ligne de
+Ã  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
@@ -125,7 +123,7 @@
 
 @item Définissez @code{mBreak = @{\break @}} et inserez
 @code{\mBreak} dans le fichier d'entrée à chaque fois que la
-partition originale change de système.  Cela rend plus facile
+partition originale change de système. Cela rend plus facile
 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
@@ -143,7 +141,7 @@
 
 @itemize @bullet
 
address@hidden @strong{utilisez un identifieur pour chaque voix},
address@hidden @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, alors que la définition du 
@@ -165,9 +163,9 @@
 
 @item @strong{séparez les modifications} 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 gros projets c'est absolument vital. Nous
 pouvons avoir besoin de changer la définition de
address@hidden, mais dans ce cas nous n'aurons besoin de le faire
address@hidden, mais dans ce cas nous n'aurons besoin de le faire
 qu'une seule fois, et nous pourrons toujours éviter de
 modifier quoi que ce soit à l'intérieur de la définition
 du @code{violon}.
@@ -189,7 +187,7 @@
 @cindex variables
 @cindex identifiers
 
-Jusqu'Ã  maintenant, vous avez vu ce type de code:
+Jusqu'Ã  maintenant, vous avez vu ce type de code :
 
 @lilypond[quote,verbatim,ragged-right]
 hornNotes = \relative c'' { c4 b dis c }
@@ -213,9 +211,9 @@
 }
 @end lilypond
 
-Cependant, vous pouvez aussi utiliser ces identifieurs
+Cependant, vous pouvez aussi utiliser ces identificateurs
 (aussi connus sous le nom de variables, macros, ou commande
-(définie par l'utilisateur)) pour des modifications:
+(définie par l'utilisateur)) pour des modifications :
 
 @lilypond[quote,verbatim,ragged-right]
 dolce = \markup{ \italic \bold dolce }
@@ -237,11 +235,11 @@
 }
 @end lilypond
 
-Ces identifieurs sont évidemment utiles pour économiser
+Ces identificateurs sont évidemment utiles pour économiser
 de la frappe. Mais ils peuvent l'être même si
 vous ne les utilisez qu'une seule fois -- ils réduisent
 la complexité. Regardons l'exemple précédent sans aucun
-identifieur. C'est beaucoup plus laborieux à lire,
+identificateur. C'est beaucoup plus laborieux à lire,
 et particulièrement la dernière ligne.
 
 @example
@@ -280,7 +278,7 @@
 }
 @end lilypond
 
-Utiliser les identifieurs est aussi un bon moyen de réduire
+Utiliser les identificateurs est aussi un bon moyen de réduire
 le travail si la syntaxe de LilyPond change (voir @ref{Updating
 old files}). Si vous avez une seule définition (comme
 @code{\dolce}) pour tous vos fichiers (voir @ref{Style sheets}),
@@ -291,12 +289,12 @@
 @node Style sheets
 @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
+La sortie que produit LilyPond peut être largement modifiée ;
+voir @ref{Tweaking output} pour plus de détails. Mais que faire
 si vous avez beaucoup de fichiers auxquels vous souhaitez
-appliquer vos modifications?  Ou si vous souhaitez simplement
+appliquer vos modifications ? Ou si vous souhaitez simplement
 séparer les modifications de la musique sur laquelle vous
-travailler?  Rien de plus facile...
+travaillez ?  Rien de plus facile...
 
 Regardons un exemple. Ne vous inquiétez pas si vous ne
 comprenez pas les parties avec tous les #(). Celles-ci
@@ -320,10 +318,11 @@
 }
 @end lilypond
 
-Il y a quelques problèmes de chevauchements ; nous allons arranger cela en 
utilisant les techniques de @ref{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 piece.  Nous pourrions simplement les copier et coller au début 
de chaque fichier, mais c'est fastidieux.
+Il y a quelques problèmes de chevauchements ; 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} et @code{tempoMark}. Elles produisent le
+résultat que nous désirons, mais nous pourrions aussi vouloir les utiliser 
dans une autre piece. Nous pourrions simplement les copier et coller au début 
de chaque fichier, mais c'est fastidieux.
 De plus, cela laisse les définitions dans nos fichiers de
 musique, et je trouve personnellement tous les #() assez laids.
 Cachons-les dans un autre fichier :
@@ -381,13 +380,13 @@
 Le glissando est difficile à voir, c'est pourquoi nous allons
 le rendre plus épais et plus proche des têtes de notes.
 Déplaçons l'indication métronomique au-dessus de la clef,
-au lieu de le laisser au-dessus de la première note.
+au lieu de la laisser au-dessus de la première note.
 Et pour finir, mon professeur de composition déteste les
 chiffrages de mesure en "C", nous allons donc le transformer
 en "4/4".
 
 Ne changez pas cependant le fichier @file{music.ly}.
-Remplacez le fichier @file{definitions.ly} avec ceci :
+Remplacez le fichier @file{definitions.ly} par ceci :
 
 @example
 %%%  definitions.ly
@@ -448,11 +447,11 @@
 }
 @end lilypond
 
-C'est déjà mieux ! Mais supposons maintenant que
-je veuille publier cette piece.  Mon professeur de composition
+C'est déjà mieux ! Mais supposons maintenant que
+je veuille publier cette piece. Mon professeur de composition
 n'aime pas les chiffrages de mesure en "C", mais moi je les
 aime bien.  Copions l'actuel @file{definitions.ly} dans le
-fichier @file{web-publish.ly}, et modifions-le.  Puisque la
+fichier @file{web-publish.ly}, et modifions-le. Puisque la
 musique est déstinée à produire un fichier pdf affiché sur
 écran, nous allons aussi augmenter la taille générale de
 la sortie.
@@ -515,18 +514,18 @@
 @end lilypond
 
 Il ne nous reste plus qu'Ã  remplacer
address@hidden "definitions.ly"} avec
address@hidden "definitions.ly"} par
 @code{\include "web-publish.ly"} dans notre fichier de musique.
 
-Il est possible bien sûr de rendre cela encore plus pratique. 
+Il est possible, bien sûr, de rendre cela encore plus pratique. 
 Nous pourrions créer un fichier @file{definitions.ly} qui
 ne contiendrait que les définitions de @code{mpdolce} et de
 @code{tempoMark}, un fichier @file{web-publish.ly} qui ne
-contiendrait que la section @code{layout} décrite ci-dessus,
+contiendrait que la section @code{layout} décrite ci-dessus
 et un fichier @file{university.ly} qui ne contiendrait
 que les modifications pour produire la sortie que mon
-professeur préfère.  Le début du fichier @file{music.ly}
-ressemblerait alors à cela:
+professeur préfère. Le début du fichier @file{music.ly}
+ressemblerait alors à cela :
 
 @example
 \include "definitions.ly"
@@ -557,28 +556,29 @@
 
 La syntaxe de LilyPond change de temps en temps. Cette syntaxe
 (le langage d'entrée) est modifiée pour accompagner les
-améliorations du logiciel.  Ces changements sont parfois destinés à rendre 
les fichiers plus faciles à lire et écrire,
-et parfois sont là pour intégrer de nouvelles fonctions.
+améliorations du logiciel. Ces changements sont parfois destinés à 
+rendre les fichiers plus faciles à lire et écrire,
+et parfois sont là pour intégrer de nouvelles fonctions.
 
 LilyPond est fourni avec un utilitaire qui facilite la
-mise-Ã -jour : @code{convert-ly}.  Pour savoir comment utiliser
+mise-Ã -jour : @code{convert-ly}. Pour savoir comment utiliser
 ce programme, voir @ref{Updating files with convert-ly}.
 
 Malheureusement, @code{convert-ly} ne peut pas réaliser tous
-les changements.  Il s'occupe de simples changements qui ne
+les changements. Il s'occupe de simples changements qui ne
 requièrent qu'un rechercher-remplacer (comme @code{raggedright}
 qui devient @code{ragged-right}), les autres étant trop
-compliqués à effectuer.  Les changements de syntaxe qui ne
+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}.
 
 Par exemple, dans les versions 2.4 et antérieures de LilyPond,
 les accents et les lettres non-anglaises étaient entrées en
-utilisant LaTeX -- par exemple, @samp{No\"el}.  A partir de la
+utilisant LaTeX -- par exemple, @samp{No\"el}.  À partir de la
 version 2.6, le caratère @samp{ë} doit être entré directement
 dans le fichier LilyPond comme caractère UTF-8.  
 @code{convert-ly} ne peut pas changer tous les caractères
-LaTeX en caractères UTF-8; Vous devez mettre-à -jour vos vieux
+LaTeX en caractères UTF-8 ; vous devez mettre-à -jour vos vieux
 fichiers LilyPond manuellement.
 
 
@@ -587,19 +587,19 @@
 @section Troubleshooting (taking it all apart)
 
 Tôt ou tard, vous écrirez un fichier que LilyPond ne peut
-pas compiler.  Les messages que LilyPond affiche peuvent
+pas compiler. Les messages que LilyPond affiche peuvent
 vous aider à trouver l'erreur, mais dans beaucoup de cas
 vous aurez besoin de faire quelques recherches pour
 déterminer la source du problème.
 
 Les outils les plus puissants pour cet usage sont la ligne
 de commentaires (indiquée par @code{%}), et le bloc de
-commentaires (indiqués par @address@hidden ... address@hidden).  Si vous
-ignorez où le problème se situe, commencez par mettre en
+commentaires (indiqués par @address@hidden ... address@hidden). Si vous
+ne pouvez localiser le problème, commencez par mettre en
 commentaires de grandes parties de votre fichier d'entrée.
 Après avoir mis en commentaires une section, essayez
 de compiler à nouveau. Si cela fonctionne, c'est que le
-problème se situe dans cette partie du fichier.  Si cela
+problème se situe dans cette partie du fichier. Si cela
 ne fonctionne pas, continuez à mettre en commentaires
 d'autres sections, jusqu'Ã  ce que vous ayez quelque chose
 qui compile.