Subject: traduction de "working"

From: "Ludovic Sardain" <[email-masked]>
Date: Tue, 23 Jan 2007 16:52:10 +0100

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é

à bientôt

Ludovic

---

From: "Valentin Villenave" <[email-masked]>
Date: Tue, 23 Jan 2007 18:13:25 +0100

Salut Ludovic,

j'ai corrigé 2-3 fautes et proposés quelques formulations plus
"françaises" à quelques endroits.
À part ça, c'est du très bon boulot. (n'oublie pas à l'avenir de
rajouter un espace avant lees ponctuations doubles)

Cordialement,
Valentin Villenave

2007/1/23, Ludovic Sardain <[email-masked]>:
> _______________________________________________
> liste de diffusion lilypond-user-fr
> [email-masked]
> http://lists.gnu.org/mailman/listinfo/lilypond-user-fr
>
>
>
>

---

From: Jean-Charles <[email-masked]>
Date: Tue, 23 Jan 2007 21:11:04 +0100

> 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
-@item Si vous faites une erreur, la structure du fichier LilyPond
+@item 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.
 
-@item @strong{Une mesure par ligne de texte}.  S'il y a quelque 
+@item @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.
 
-@item @strong{Commentez vos fichiers}.  Utilisez soit des
+@item @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é.
 
-@item @strong{Indentez vos crochets}.  Beaucoup de problèmes
-viennent de la différence de nombre de @code{@{] et de @code{@}}.
+@item @strong{Indentez vos crochets}. Beaucoup de problèmes
+viennent d'un défaut de parité entre @code{@{] et @code{@}}.
 
 @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
 
-@item @strong{utilisez un identifieur 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, 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
-@code{fthemp}, mais dans ce cas nous n'aurons besoin de le faire
+@code{fthenp}, 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
-@code{\include "definitions.ly"} avec
+@code{\include "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 @code{%@{ ... %@}}).  Si vous
-ignorez où le problème se situe, commencez par mettre en
+commentaires (indiqués par @code{%@{ ... %@}}). 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.

---

From: "Valentin Villenave" <[email-masked]>
Date: Wed, 24 Jan 2007 09:55:37 +0100

> en compte lorsque l'on écrit un fichier LilyPond. »

Bien vu, je l'avais laissée passer. Ci-joint un nouveau fichier
(peux-tu refaire le diff s'il te plaît, je ne dispose pas de cette
commande sur mon ordi...).
Je propose :

"Maintenant vous êtes prêt à travailler sur de plus gros fichiers
LilyPond -- des pièces entières, et plus seulement les petits
exemples du tutoriel.  Mais comment allez-vous vous y prendre pour commencer ?

Tant que LilyPond parvient à comprendre vos fichiers et produit le
résultat que vous souhaitez, peu importe la manière dont vous
organisez votre code.  Cependant, quelques autres critères doivent
être pris en compte lorsque l'on écrit un fichier LilyPond."

Cordialement,
Valentin Villenave.

---

From: "Valentin Villenave" <[email-masked]>
Date: Wed, 24 Jan 2007 10:00:37 +0100

> Bien vu, je l'avais laissée passer. Ci-joint un nouveau fichier

Flûte....

Jean-Charles, je viens de voir sur ton diff que tu as ajouté quelques
corrections (excellentes au demeurant) de ton crû au fichier que
j'avais envoyé. Du coup, ne tiens pas compte du fichier que je viens
de renvoyer (qui est fondé sur mon ancienne version, et de ce fait
n'intègre pas tes corrections) ; tu peux garder ton fichier, et juste
y ajouter le petit paragraphe que j'ai retraduit (en le modifiant si
tu le souhaites).

---

From: Jean-Charles <[email-masked]>
Date: Wed, 24 Jan 2007 19:10:30 +0100

> y ajouter le petit paragraphe que j'ai retraduit (en le modifiant si

Pour éviter toute fausse route, ou mauvaise manipulation, voici un 
différentiel par rapport à l'original de Ludovic et ma dernière version, 
à utiliser selon votre préférence.

Bonne soirée, je retourne à mon « Ave maris stella » des vêpres.

Jean-Charles
@c -*- coding: utf-8; mode: texinfo; documentlanguage: fr -*-
@c This file is part of lilypond.tely
@ignore
    Translation of GIT committish: 64f0d86a7c0987b311bfdfdfeddfa063e1f2d6e7

    When revising a translation, copy the HEAD committish of the
    version that you are working on.  See TRANSLATION for details.
@end ignore

@node Working on LilyPond projects
@chapter Working on LilyPond projects

Cette section explique comment résoudre ou éviter certains
problèmes courants.  Si vous avez une expérience dans la
programmation, beaucoup de ces astuces peuvent vous paraître
évidentes.  Cependant, il est quand même conseillé de lire
ce chapitre.

@menu 
* Suggestions for writing LilyPond files::
* Saving typing with identifiers and functions::
* Style sheets::
* Updating old files::
* Troubleshooting (taking it all apart)::
@end menu 
@node Suggestions for writing LilyPond files
@section Suggestions for writing LilyPond files

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 allez-vous vous y prendre pour
commencer ?

Tant que LilyPond parvient à comprendre vos fichiers et produit le
résultat que vous souhaitez, pei importe la manière dont vous le code
est organisé. Néanmoins, quelques autres critères doîvent être pris en
en compte lorsque l'on écrit un fichier LilyPond.

@itemize @bullet
@item 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 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
du langage d'entrée change quelques fois lorsque LilyPond
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
à jour.
@end itemize

@menu 
* General suggestions::
* Typesetting existing music::
* Large projects::
@end menu 
@node General suggestions
@subsection General suggestions

Voici quelques conseils qui peuvent vous éviter certains problèmes ou en résoudre d'autres:

@itemize @bullet
@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é.

@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. À 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.

@item @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
huit mesures par ligne n'a que peu de valeur si vous devez
corriger vos fichiers.

@item @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
vous écrivez une pièce pour la première fois, mais si vous
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é.

@item @strong{Indentez vos crochets}. Beaucoup de problèmes
viennent d'un défaut de parité entre @code{@{] et @code{@}}.

@item @strong{Séparez les modifications} des définitions de
musique.  Voyez @ref{Saving typing with identifiers and
functions} et @ref{Style sheets}.

@end itemize

@node Typesetting existing music
@subsection Typesetting existing music

Si vous saisissez de la musique depuis une partition existante
(c'est-à-dire d'une musique déjà écrite),

@itemize @bullet

@item N'entrez qu'un seul système de la partition originale
à 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}.

@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
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
les sauts de ligne, et laisser LilyPond changer de système
quand il le souhaite.

@end itemize

@node Large projects
@subsection Large projects

Lorsque l'on travaille sur un gros projet, il devient vital
d'avoir une structure claire des fichiers LilyPond.

@itemize @bullet

@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, alors que la définition du 
@code{violon} ne l'est que très peu.

@example
violin = \relative c'' @{
g4 c'8. e16
@}
...
\score @{
  \new GrandStaff @{
    \new Staff @{
      \violin
    @}
  @}
@}
@end example

@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
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 toujours éviter de
modifier quoi que ce soit à l'intérieur de la définition
du @code{violon}.

@example
fthenp = _\markup@{
  \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
violin = \relative c'' @{
g4\fthenp c'8. e16
@}
@end example

@end itemize

@node Saving typing with identifiers and functions
@section Saving typing with identifiers and functions

@cindex variables
@cindex identifiers

Jusqu'à maintenant, vous avez vu ce type de code :

\score {
  {
    \hornNotes
  }
}
@end lilypond

Vous comprendrez combien cela peut être utile pour écrire de la musique minimaliste :

@lilypond[quote,verbatim,ragged-right]
fragA = \relative c'' { a4 a8. b16 }
fragB = \relative c'' { a8. gis16 ees4 }
violin = \new Staff { \fragA \fragA \fragB \fragA }
\score {
  {
    \violin
  }
}
@end lilypond

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 :

@lilypond[quote,verbatim,ragged-right]
dolce = \markup{ \italic \bold dolce }
padText = { \once \override TextScript #'padding = #5.0 }
fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
violin = \relative c'' {
  \repeat volta 2 {
    c4._\dolce b8 a8 g a b |
    \padText
    c4.^"hi there!" d8 e' f g d |
    c,4.\fthenp b8 c4 c-. |
  }
}
\score {
  {
    \violin
  }
\layout{ragged-right=##t}
}
@end lilypond

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
identificateur. C'est beaucoup plus laborieux à lire,
et particulièrement la dernière ligne.

@example
violin = \relative c'' @{
  \repeat volta 2 @{
    c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
    \once \override TextScript #'padding = #5.0
    c4.^"hi there!" d8 e' f g d |
    c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
      \hspace #0.1 \dynamic p @} b8 c4 c-. |
  @}
@}
@end example

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=}).

LilyPond peut gérer é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
  #})

\relative c''' {
  c4^"piu mosso" b a b
  \padText #1.8
  c4^"piu mosso" d e f
  \padText #2.6
  c4^"piu mosso" fis a g
}
@end lilypond

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}),
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}.

@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
si vous avez beaucoup de fichiers auxquels vous souhaitez
appliquer vos modifications ? Ou si vous souhaitez simplement
séparer les modifications de la musique sur laquelle vous
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
sont expliquées dans @ref{Advanced tweaks with Scheme}.

@lilypond[quote,verbatim,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup { \bold $markp }
#})

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@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 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 :

@example
%%% save this to a file called "definitions.ly"
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#@{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup @{ \bold $markp @}
#@})
@end example

Maintenant, modifions notre musique (enregistrez ce fichier
sous @file{"music.ly"}).

@c  We have to do this awkward example/lilypond-non-verbatim
@c  because we can't do the \include stuff in the manual.

@example

\relative c'' @{
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup { \bold $markp }
#})

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

C'est mieux, mais ajoutons encore quelques modifications.
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 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} par ceci :

@example
%%%  definitions.ly
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#@{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup @{ \bold $markp @}
#@})

\layout@{
  \context @{ \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  @}
  \context @{ \Staff
    \override TimeSignature #'style = #'numbered
  @}
  \context @{ \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  @}
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup { \bold $markp }
#})

\layout{
  \context { \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  }
  \context { \Staff
    \override TimeSignature #'style = #'numbered
  }
  \context { \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  }
}

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

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
musique est déstinée à produire un fichier pdf affiché sur
écran, nous allons aussi augmenter la taille générale de
la sortie.

@example
%%%  definitions.ly
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#@{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup @{ \bold $markp @}
#@})

#(set-global-staff-size 23)
\layout@{
  \context @{ \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  @}
  \context @{ \Staff
  @}
  \context @{ \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  @}
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup { \bold $markp }
#})

#(set-global-staff-size 23)
\layout{
  \context { \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  }
  \context { \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  }
}

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Il ne nous reste plus qu'à remplacer
@code{\include "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. 
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
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 :

@example

%%%  Only uncomment one of these two lines!
\include "web-publish.ly"
%\include "university.ly"
@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 @q{style sheet} pour mes projets. Je
commence chaque fichier musical par
@code{\include "../global.ly"} qui contient :

@example
%%%   global.ly
\version "2.9.13"
#(ly:set-option 'point-and-click #f)
\include "../init/init-defs.ly"
\include "../init/init-layout.ly"
\include "../init/init-headers.ly"
\include "../init/init-paper.ly"
@end example

@node Updating old files
@section Updating old files

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.

LilyPond est fourni avec un utilitaire qui facilite la
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
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
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}.  À 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
fichiers LilyPond manuellement.

@node Troubleshooting (taking it all apart)
@section Troubleshooting (taking it all apart)

pas compiler. Les messages que LilyPond affiche peuvent

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 @code{%@{ ... %@}}). 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
ne fonctionne pas, continuez à mettre en commentaires
d'autres sections, jusqu'à ce que vous ayez quelque chose
qui compile.

Dans un cas extrême, vous pourriez arriver à ceci :

@example
\score @{
  <<
    % \melody
    % \harmony
    % \bass
  \layout@{@}
@}
@end example

@noindent
(c'est-à-dire un fichier sans aucune musique)

Si cela arrive, ne vous découragez pas. Décommentez un peu,
la partie de basse par exemple, et voyez si ça fonctionne.
Si ce n'est pas le cas, placez en commentaires toute la
partie de basse, mais laissez décommenté @code{\bass} dans
le bloc @code{\score}.

@example
bass = \relative c' @{
%@{
  c4 c c c
  d d d d
%@}
@}
@end example

Maintenant commencez à décommenter petit à petit en partant de votre définition de @code{bass} jusqu'à ce que
vous localisiez la ligne qui pose problème.

--- working.itely	2007-01-24 18:52:32.000000000 +0100
+++ working.itely.new	2007-01-24 18:49:38.000000000 +0100
@@ -28,28 +28,27 @@
 
 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 comment allez-vous vous y prendre pour
+commencer ?
 
-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
+Tant que LilyPond parvient à comprendre vos fichiers et produit le
+résultat que vous souhaitez, pei importe la manière dont vous le code
+est organisé. Néanmoins, quelques autres critères doîvent être pris en
 en compte lorsque l'on écrit un fichier LilyPond.
 
 @itemize @bullet
 
-@item Et si vous souhaites partager vos fichiers avec quelqu'un
+@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.
 
@@ -64,46 +63,42 @@
 @node General suggestions
 @subsection General suggestions
 
-Voici quelques conseils qui peuvent vous éviter ou résoudre des
-problèmes:
+Voici quelques conseils qui peuvent vous éviter certains problèmes ou en résoudre d'autres:
 
 @itemize @bullet
 @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é.

 

@@ -121,7 +116,7 @@
 @itemize @bullet
 
@@ -129,12 +124,12 @@
 
 @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
 les sauts de ligne, et laisser LilyPond changer de système
-lorsque qu'il juge que c'est le mieux.
+quand il le souhaite.
 
 @end itemize
 
@@ -147,7 +142,7 @@
 
 @itemize @bullet
 
@@ -169,10 +164,10 @@
 
 @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
-@code{fthemp}, but alors nous n'avons besoin de le faire
-qu'une seule fois, et nous pouvons toujours éviter de
+@code{fthenp}, 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}.
 
@@ -193,7 +188,7 @@
 @cindex variables
 @cindex identifiers

@@ -204,8 +199,7 @@
 }
 @end lilypond
 
-Vous pouvez même réaliser que cela peut être utile en musique
-minimaliste:
+Vous comprendrez combien cela peut être utile pour écrire de la musique minimaliste :
 
 @lilypond[quote,verbatim,ragged-right]
 fragA = \relative c'' { a4 a8. b16 }
@@ -218,9 +212,9 @@
 }
 @end lilypond

@@ -242,11 +236,11 @@
 }
 @end lilypond

 @example
@@ -285,10 +279,10 @@
 }
 @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{\doce}) pour tous vos fichiers (voir @ref{Style sheets}),
+@code{\dolce}) pour tous vos fichiers (voir @ref{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}.
@@ -296,12 +290,12 @@
 @node Style sheets
 @section Style sheets
 
-travailler?  C'est assez facile à réaliser.
 
@@ -325,16 +319,14 @@
 }
 @end lilypond
 
-Il y a quelques problèmes de chevauchements; nous allons les
-fixez en utilisant les techniques de @ref{Moving objects}.
-Nous allons aussi faire quelquechose pour les définitions
-de @code{mpdolce} et @code{tempoMark}.  Elles produisent le
-résultat que nous désirons, mais nous voudrions les utiliser
-dans une autre piece.  Nous pourrions simplement les copier et
-coller au début de chauqe 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:
+Cachons-les dans un autre fichier :
 
 @example
 %%% save this to a file called "definitions.ly"
@@ -386,16 +378,16 @@
 @end lilypond
 
 C'est mieux, mais ajoutons encore quelques modifications.
-Le glissando est difficile à voir, alors nous allons
+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.
-Et finallement, mon professeur de composition déteste les
+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
@@ -456,11 +448,11 @@
 }
 @end lilypond
 
-Le résultat est meilleur! Mais supposons maintenant que
@@ -523,18 +515,18 @@
 @end lilypond

 
 @example
@@ -565,29 +557,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.  Quelques fois ces changements sont
-fait pour rendre les fichiers plus facile à lire et écrire,
-et d'autres fois 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
+LilyPond est fourni avec un utilitaire qui facilite la
+mise-à-jour : @code{convert-ly}. Pour savoir comment utiliser
 ce programme, voir @ref{Updating files with convert-ly}.

@@ -596,19 +588,19 @@
 
-pas compiler.  Les messages que LilyPond donnent peuvent
 
@@ -629,7 +621,7 @@
 @noindent
 (c'est-à-dire un fichier sans aucune musique)
 
-Si cela arrive, ne laissez pas tomber. Décommentez un peu,
+Si cela arrive, ne vous découragez pas. Décommentez un peu,
 la partie de basse par exemple, et voyez si ça fonctionne.
 Si ce n'est pas le cas, placez en commentaires toute la
 partie de basse, mais laissez décommenté @code{\bass} dans
@@ -644,7 +636,6 @@
 @}
 @end example
 
-Maintenant commencez à décommenter petit à petit de plus
-en plus de la définition de @code{bass} jusqu'à ce que
+Maintenant commencez à décommenter petit à petit en partant de votre définition de @code{bass} jusqu'à ce que
 vous localisiez la ligne qui pose problème.

---

From: Jean-Jacques Rétorré <[email-masked]>
Date: Wed, 24 Jan 2007 19:45:39 +0100

Bonjour,
J'utilise Emacs pour éditer le code ly et le mode lyqi de Nicolas 
Sceaux. J'aimerais pouvoir insérer des commentaires sans avoir à quitter 
ce mode.
Je n'ai pas trouvé comment insérer «% Mesure xx» de manière simple.
Quelqu'un a-t-il une solution ? (pour l'instant je crée #%Mesure xx et 
j'efface le caractère # :-(
Merci
JJR.

-- 
Jean-Jacques Rétorré

% Les gens qui ne rient jamais ne sont pas des gens sérieux (A. Allais).
--

---

From: Jean-Yves Baudais <[email-masked]>
Date: Thu, 25 Jan 2007 09:49:11 +0100

Bonjour,

   Puisqu'à une époque j'avais des remarques sur un fichier, je m'y suis 
mis moi aussi. Que du détail. Par contre la façon de procéder n'est 
peut-être pas terrible, si une autre personne part du même fichier mais 
postes ses modifications après moi, qui va *re*-faire le boulot ?

--Jyb
%% diff working.itely.new workin.itely
%% iff (GNU diffutils) 2.8.1
%% working.itely.new 20/01/2007
%% working.itely : pièce jointe au courriel de "Jean-Charles 
%%                 <[email-masked]>"  sur lilypond-user-fr
%%                 le 24/01/2007 à 19h10

14c14
< problèmes courants.  Si vous avez une expérience en 
---
> problèmes courants.  Si vous avez une expérience dans la
35,36c35,36
< résultat que vous souhaitez, peu importe la manière dont le code
< est organisé. Néanmoins, quelques critères doîvent être pris
---
> est organisé. Néanmoins, quelques autres critères doîvent être pris en
51c51
< s'améliore. La plupart des modifications peuvent être faites
---
> s'améliore. La plupart des modification peuvent être faites
53c53
< peuvent demander une intervention manuelle. Les fichiers LilyPond
---
> peuvent demander une intervention manuelle. Les fichier LilyPond
66c66
< Voici quelques conseils qui peuvent vous éviter certains problèmes ou en résoudre d'autres :
---
> Voici quelques conseils qui peuvent vous éviter certains problèmes ou en résoudre d'autres:
77c77
< retrouver plus rapidement. À quelle fréquence faut-il en ajouter ? 
---
> retrouver plus rapidement. À quelle fréquence faut-il en ajouter? 
216,217c216,217
< (aussi connus sous le nom de variables, macros, ou commandes
< définies par l'utilisateur) pour des modifications :
---
> (définie par l'utilisateur)) pour des modifications :
326c326
< résultat que nous désirons, mais nous pourrions aussi vouloir les utiliser dans une autre pièce. Nous pourrions simplement les copier et les coller au début de chaque fichier, mais c'est fastidieux.
---
> 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.
456c456
< musique est destinée à produire un fichier pdf affiché sur
---
> musique est déstinée à produire un fichier pdf affiché sur
561c561
< rendre les fichiers plus faciles à lire et à écrire,
---
> rendre les fichiers plus faciles à lire et écrire,
598c598
< commentaires (indiqué par @code{%@{ ... %@}}). Si vous
---
> commentaires (indiqués par @code{%@{ ... %@}}). Si vous
601c601
< Après avoir mis en commentaire une section, essayez
---
> Après avoir mis en commentaires une section, essayez
604c604
< ne fonctionne pas, continuez à mettre en commentaire
---
> ne fonctionne pas, continuez à mettre en commentaires
626c626
< Si ce n'est pas le cas, placez en commentaire toute la
---

Cette section explique comment résoudre ou éviter certains
problèmes courants.  Si vous avez une expérience en 
programmation, beaucoup de ces astuces peuvent vous paraître
évidentes.  Cependant, il est quand même conseillé de lire
ce chapitre.

@menu 

Tant que LilyPond parvient à comprendre vos fichiers et produit le
résultat que vous souhaitez, peu importe la manière dont le code
est organisé. Néanmoins, quelques critères doîvent être pris
en compte lorsque l'on écrit un fichier LilyPond.

@itemize @bullet

@item Et si vous souhaitez mettre à jour votre fichier pour
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 modifications peuvent être faites
automatiquement avec @code{convert-ly}, mais quelques-unes
peuvent demander une intervention manuelle. Les fichiers LilyPond
peuvent être structurés de manière à être plus faciles à mettre
à jour.
@end itemize

@menu 
* General suggestions::

Voici quelques conseils qui peuvent vous éviter certains problèmes ou en résoudre d'autres :

@itemize @bullet

retrouver plus rapidement. À quelle fréquence faut-il en ajouter ? 

@end itemize

@itemize @bullet

@end itemize

@node Large projects

@itemize @bullet

@example

@example
fthenp = _\markup@{

@end itemize

@cindex variables
@cindex identifiers

Cependant, vous pouvez aussi utiliser ces identificateurs
(aussi connus sous le nom de variables, macros, ou commandes
définies par l'utilisateur) pour des modifications :

@example

\relative c''' {
  c4^"piu mosso" b a b
  \padText #1.8
  c4^"piu mosso" d e f
  \padText #2.6
  c4^"piu mosso" fis a g
}
@end lilypond

@node Style sheets
@section Style sheets

\relative c'' {
  \tempo 4=50

résultat que nous désirons, mais nous pourrions aussi vouloir les utiliser dans une autre pièce. Nous pourrions simplement les copier et les coller au début de chaque fichier, mais c'est fastidieux.

@example

@example

\relative c'' @{
  \tempo 4=50

\relative c'' {
  \tempo 4=50

@example
%%%  definitions.ly

\layout@{
  \context @{ \Score

\layout{
  \context { \Score

\relative c'' {
  \tempo 4=50

musique est destinée à produire un fichier pdf affiché sur

@example
%%%  definitions.ly

\relative c'' {
  \tempo 4=50

@example

@example
%%%   global.ly
\version "2.9.13"

@node Updating old files

rendre les fichiers plus faciles à lire et à écrire,

Les outils les plus puissants pour cet usage sont la ligne
de commentaires (indiquée par @code{%}), et le bloc de
commentaires (indiqué par @code{%@{ ... %@}}). 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 commentaire une section, essayez
de compiler à nouveau. Si cela fonctionne, c'est que le
problème se situe dans cette partie du fichier. Si cela
ne fonctionne pas, continuez à mettre en commentaire
d'autres sections, jusqu'à ce que vous ayez quelque chose
qui compile.

@example
\score @{
  <<
    % \melody
    % \harmony
    % \bass
  \layout@{@}
@}
@end example

@noindent

Si cela arrive, ne vous découragez pas. Décommentez un peu,
la partie de basse par exemple, et voyez si ça fonctionne.
Si ce n'est pas le cas, placez en commentaire toute la
partie de basse, mais laissez décommenté @code{\bass} dans
le bloc @code{\score}.

@example
bass = \relative c' @{
%@{
  c4 c c c
  d d d d
%@}
@}
@end example

---

From: John Mandereau <[email-masked]>
Date: Thu, 25 Jan 2007 23:09:47 +0100

> postes ses modifications après moi, qui va *re*-faire le boulot ?

Il y a deux possibilités.  Soit on fonctionne comme aujourd'hui :
n'importe qui contribue n'importe quand, et on se débrouille après pour
fusionner les modifications ; soit chaque contributeur doit annoncer sur
la liste qu'il veut effectuer une relecture ou traduction, celle-ci est
alors "verrouillée" (personne ne doit plus y toucher) jusqu'à ce que le
contributeur envoie son travail sur la liste ou qu'un délai raisonnable
ait expiré (je dirais une semaine pour une relecture, un mois pour une
première traduction).

Vu que l'équipe de traduction commence à être conséquente, il pourrait
être intéressant de tester la deuxième méthode ; qu'en pensez-vous ?

À propos, où en sont les traducteurs de preface.itely, putting.itely et
basic-notation.itely ? ;-)

Jean-Yves, pourrais-tu envoyer les différences unifiées plutôt (avec
diff -u) ?  Les diff brutes sont peu lisibles et se patchent parfois
avec plus de difficultés.

Bien cordialement
-- 
John Mandereau <[email-masked]>

---

From: Jean-Yves Baudais <[email-masked]>
Date: Fri, 26 Jan 2007 09:24:50 +0100

Bonjour,

John Mandereau a écrit :
> Jean-Yves, pourrais-tu envoyer les diffÃ©rences unifiÃ©es plutÃ´t (avec
> avec plus de difficultÃ©s.

   Zut, j'ai plus les sources. Bon j'ai récupéré les deux fichiers dans 
les archives de la listes et lancé "diff- u" dessus (pas vu d'erreur). 
Deux remarques : 1) comment récupérer un fichier joint dans les archives 
(j'ai comme l'impression que ça n'existe pas un fichier en tant que 
pièce jointe), 2) serait-il possible quand vous répondez à mes messages 
de ne pas m'envoyer la réponse à mon adresse perso, mais seulement à la 
liste (comme je suis abonné...;-).
   Merci.

--Jyb
--- working.itely.new	2007-01-26 09:16:38.000000000 +0100
+++ working.itely	2007-01-26 09:16:03.000000000 +0100
@@ -11,7 +11,7 @@
 @chapter Working on LilyPond projects
 
 Cette section explique comment résoudre ou éviter certains
-problèmes courants.  Si vous avez une expérience en 
+problèmes courants.  Si vous avez une expérience dans la
 programmation, beaucoup de ces astuces peuvent vous paraître
 évidentes.  Cependant, il est quand même conseillé de lire
 ce chapitre.
@@ -32,8 +32,8 @@
 commencer ?
 
 Tant que LilyPond parvient �  comprendre vos fichiers et produit le
-résultat que vous souhaitez, peu importe la manière dont le code
-est organisé. Néanmoins, quelques critères doîvent être pris
+résultat que vous souhaitez, pei importe la manière dont vous le code
+est organisé. Néanmoins, quelques autres critères doîvent être pris en
 en compte lorsque l'on écrit un fichier LilyPond.
 
 @itemize @bullet
@@ -48,9 +48,9 @@
 @item Et si vous souhaitez mettre �  jour votre fichier pour
 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 modifications 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 fichiers LilyPond
+peuvent demander une intervention manuelle. Les fichier LilyPond
 peuvent être structurés de manière �  être plus faciles �  mettre
 �  jour.
 @end itemize
@@ -64,7 +64,7 @@
 @subsection General suggestions
 
 Voici quelques conseils qui peuvent vous éviter certains problèmes ou en 
-résoudre d'autres :
+résoudre d'autres:
 
 @itemize @bullet
 @item @strong{ajoutez les numéros de version dans chaque fichier}. 
@@ -78,7 +78,7 @@
 @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. �? quelle fréquence faut-il en ajouter ? 
+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.
@@ -218,8 +218,8 @@
 @end lilypond
 
 Cependant, vous pouvez aussi utiliser ces identificateurs
-(aussi connus sous le nom de variables, macros, ou commandes
-définies par l'utilisateur) pour des modifications :
+(aussi connus sous le nom de variables, macros, ou commande
+(définie par l'utilisateur)) pour des modifications :
 
 @lilypond[quote,verbatim,ragged-right]
 dolce = \markup{ \italic \bold dolce }
@@ -330,8 +330,8 @@
 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 pièce. Nous pourrions simplement les copier et les coller au 
-début de chaque fichier, mais c'est fastidieux.
+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 :
@@ -465,7 +465,7 @@
 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
-musique est destinée �  produire un fichier pdf affiché sur
+musique est déstinée �  produire un fichier pdf affiché sur
 écran, nous allons aussi augmenter la taille générale de
 la sortie.
 
@@ -572,7 +572,7 @@
 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,
+rendre les fichiers plus faciles �  lire et écrire,
 et parfois sont l�  pour intégrer de nouvelles fonctions.
 
@@ -609,13 +609,13 @@
 
 Les outils les plus puissants pour cet usage sont la ligne
 de commentaires (indiquée par @code{%}), et le bloc de
-commentaires (indiqué par @address@hidden ... address@hidden). Si vous
+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 commentaire une section, essayez
+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
-ne fonctionne pas, continuez �  mettre en commentaire
+ne fonctionne pas, continuez �  mettre en commentaires
 d'autres sections, jusqu'�  ce que vous ayez quelque chose
 qui compile.
 
@@ -637,7 +637,7 @@
 
 Si cela arrive, ne vous découragez pas. Décommentez un peu,
 la partie de basse par exemple, et voyez si ça fonctionne.
-Si ce n'est pas le cas, placez en commentaire toute la
+Si ce n'est pas le cas, placez en commentaires toute la
 partie de basse, mais laissez décommenté @code{\bass} dans
 le bloc @code{\score}.

---

From: "Valentin Villenave" <[email-masked]>
Date: Fri, 26 Jan 2007 10:12:29 +0100

2007/1/25, Valentin Villenave <[email-masked]>:

http://lilypondwiki.tuxfamily.org/index.php?title=Working.itely

> Si quelqu'un trouve que c'est une mauvaise idée, n'hésitez pas à le dire.

Allô ? ;-)

En tout cas, je me suis permis de reprendre sur le Wiki l'ensemble du
texte, et la version qui s'y trouve actuellement me paraît tout à fait
potable.

John ou quelqu'un d'autre, que pensez-vous de cette manière de bosser
? Pourrait-on procéder ainsi, de telle sorte que ce soit un peu un mix
entre les deux manières de procéder que propose John ? À savoir :
-Le contributeur qui veut effectuer une traduction crée une et
_une_seule_ page sur le wiki, il l'annonce sur la liste, en mettant un
lien vers ladite page, de façon à ce que son boulot se trouve à un
seul endroit.
-Après qu'il ait posté sur le Wiki son premier jet, chaque
contributeur (y compris lui-même) vient voir, lit et relit (attention,
il vaut mieux se mettre en mode "édition" pour lire le format itely
"authentique), apportant une correction après l'autre, les discussions
sur les détails pouvant se faire soit sur le Wiki, soit sur la liste
s'il y a lieu.

Nous pouvons également procéder de la sorte pour preface.itely,
putting.itely et basic-notation.itely. Si ceux qui ont commencé à s'y
coller n'ont pas le temps d'aller jusqu'au bout ou quoi que ce soit,
ils peuvent bazarder leur travail en l'état sur le Wiki, et compter
sur les petits camarades pour finir le boulot (je suis prêt à m'y
mettre pour ma part, mais comme j'utilise pleins d'ordinateurs et d'OS
différents suivant les jours, je ne peux pas procéder par le système
de diff etc...).

En tout cas, la version de working qui se trouve au lien ci-dessus me
paraît assez aboutie (elle intègre les apports de Ludovic, de
Jean-Charles, de Jean-Yves et de bibi). Si quelqu'un veut l'entériner
et la "commettre"...

Salutations,
Valentin

---

From: John Mandereau <[email-masked]>
Date: Sat, 27 Jan 2007 16:44:11 +0100

> > Si quelqu'un trouve que c'est une mauvaise idée, n'hésitez pas à le dire.

Encadrer le tout avec <pre> et </pre> permet d'afficher le code
correctement.  La seule mauvaise idée est dans le nom de la page : si
les traducteurs epagnols veulent faire la même chose, comment
appelleront-ils la page ?  Il faudrait mettre cette page dans l'espace
de nom fr (i.e. la renommer en fr:working.itely).  À propos, ce wiki est
un vrai bazar, je recherche un administrateur qui a plus de temps que
moi, disons vingt minutes par jour en moyenne, pour mettre un peu
d'ordre dans tout ça (lier, renommer et ranger les pages en catégories).

> texte, et la version qui s'y trouve actuellement me paraît tout à fait

Tout à fait, j'ai fait quelques changements de tournure des phrases,
traduit les noms de fichiers et d'identificateurs (on n'a pas le droit
de traduire seulement ce qui ce trouve dans les blocs @lilypond), et mis
à jour d'après la dernière version en anglais.

> sur les détails pouvant se faire soit sur le Wiki, soit sur la liste

C'est globalement une bonne idée.  Du point de vue du développeur à
l'aise avec la ligne de commande, Git et un éditeur de texte avancé
colorant la syntaxe Texinfo, et qui a la possibilité de tout le temps
utiliser la même machine, cette façon de travailler est archaïque.  D'un
autre côté, cette méthode requiert moins de compétences techniques et
est beacoup plus souple.  J'ajouterai une seule restriction : je
protégerai toutes ces pages contre les éditions anonymes, car il est
indispensable de connaître tous les traducteurs et relecteurs pour les
ajouter dans THANKS (c'est souvent l'unique signe de reconnaissance de
leur travail, vu que les traducteurs doivent abandonner leurs droits
d'auteur au profit des auteurs principaux de LilyPond lors de leur
intégration aux sources officielles).

> Jean-Charles, de Jean-Yves et de bibi). Si quelqu'un veut l'entériner

Je l'ai fait à l'instant sur ma copie de dépôt Git.  Je suis pour
l'instant le responsable de toutes les écritures sur le dépôt
git.sv.gnu.org relatives à la traduction.  J'attends que la traduction
du tutoriel soit mise à jour (cf. mon courriel récent) avant de tout
envoyer sur git.sv.gnu.org, sinon la mise à jour de la doc en anglais
depuis la branche de développement désactivera les images de musique
dans toute la traduction.

Salutations lilyesques

---

From: John Mandereau <[email-masked]>
Date: Sat, 27 Jan 2007 17:02:57 +0100

> Deux remarques : 1) comment récupérer un fichier joint dans les archives 

En lisant les archives :-)

> pièce jointe),

Si, mais les pièces jointes de texte sont directement incorporées dans
le message.

À propos, j'ai par contre un gros problème avec le codage des caractères
avec Mozilla Firefox ou Konqueror, pas vous ?  Peut-être cela vient de
Mailman ou de lists.gnu.org...

> 2) serait-il possible quand vous répondez à mes messages 

Non, ce n'est pas possible.  Seul l'administrateur (et dans une moindre
mesure le modérateur) peut savoir qui est abonné à la liste, la fonction
"Répondre à tous" permet dans tous les cas d'envoyer la réponse à
l'expéditeur et à la liste, et tout abonné a la possibilité de changer
ses options d'abonnement afin de ne pas recevoir un courriel de la liste
s'il est déjà destinataire du courriel.  Je ne vois donc aucun problème,
à part le filtrage des courriels dans ton logiciel de messagerie :
personnellement, j'utilise un filtre qui déplace tous les messages dont
[email-masked] est dans le champ À ou Cc vers le dossier
lily-fr.

Salutations lilypondesques
-- 
John Mandereau <[email-masked]>

---

From: "Valentin Villenave" <[email-masked]>
Date: Sat, 27 Jan 2007 21:40:27 +0100

> d'ordre dans tout ça (lier, renommer et ranger les pages en catégories).

D'accord, c'est effectivement préférable.

Je suis content que mon idée rencontre du succès, comme certains l'ont
compris sur la liste -user, je suis assez fan des Wikis. Je peux
d'ailleurs essayer de mettre un peu d'ordre dans le Wiki si tu
m'encadres suffisamment (je n'ai jamais été admin sur un MediaWiki, je
ne connais que PmWiki).

> intégration aux sources officielles).

Je ne suis pas un codeur, et même si je l'étais, je préfère avoir
accès autrement que par GIT à la source (quitte à copier ça dans
Bluefish un instant, pour pouvoir voir les couleurs le temps de bosser
dessus).

En tout cas, bien sûr qu'on peut limiter l'accès en écriture aux
utilisateurs identifiés.

Tout ceci n'était qu'un lancement.

(PS. J'ai moi aussi un problème de codage avec les fichiers .itely qui
circulent sur la liste, sauf quand ils sont intégrés au texte des
mails, et non en pièce jointe. Pourrait-on favoriser ce mode d'envoi
?)

Cordialement,
Valentin

---

From: John Mandereau <[email-masked]>
Date: Mon, 29 Jan 2007 00:11:52 +0100

> Bluefish un instant, pour pouvoir voir les couleurs le temps de bosser

Pour l'accès aux sources, Git est beaucoup plus pratique et économique
(en temps, en bande passante et en mémoire) que ce système utilisant le
wiki.  D'ailleurs, c'est le seul moyen pour obtenir des sources à jour.
Actuellement, nous travaillons sur la branche stable, donc se baser sur
les dernières archives sources est suffisant, mais à l'approche de la
sortie de la prochaine version stable, nous concentrerons les
traductions sur la branche de développement, qu'on ne peut suivre
raisonnablement qu'avec Git.

> Tout ceci n'était qu'un lancement.

Très bien, et qui s'occupera de mettre à jour ces traductions et/ou de
les synchroniser avec le dépôt Git ?  N'oubliez pas que comme les
sources officielles sont gérées avec Git, donc nous sommes obligés de
l'utiliser pour la mise à jour des traductions.  Sauf si quelqu'un se
propose pour assurer en permanence (disons au moins 2 fois par semaine,
pour une durée indéfinie) la synchronisation de Git vers le wiki (étant
entendu que je n'assurerai jamais que la synchronisation dans l'autre
sens), je propose de limiter l'utilisation du wiki aux nouvelles
traductions.

> mails, et non en pièce jointe. Pourrait-on favoriser ce mode d'envoi

Je ne promets pas d'y penser tout le temps, mais je vais essayer.  Le
petit problème est que lorqu'on envoie plusieurs textes différents
ainsi, ça devient un vrai fouillis.