[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: traduction de "working"
From: |
Jean-Charles |
Subject: |
Re: traduction de "working" |
Date: |
Tue, 23 Jan 2007 21:11:04 +0100 |
User-agent: |
Thunderbird 1.5.0.9 (X11/20070111) |
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.
- traduction de "working", Ludovic Sardain, 2007/01/23
- Re: traduction de "working", Valentin Villenave, 2007/01/23
- Re: traduction de "working",
Jean-Charles <=
- Re: traduction de "working", Jean-Charles, 2007/01/24
- Message not available
- Re: traduction de "working", Valentin Villenave, 2007/01/26
- Re: traduction de "working", John Mandereau, 2007/01/27
- Re: traduction de "working", Valentin Villenave, 2007/01/27