Subject: Re: mise à jour des traducs du manuel de l'utilisateur

From: "Valentin Villenave" <[email-masked]>
Date: Fri, 2 Feb 2007 12:12:21 +0100

Bonjour à tous,

j'ai proposé sur le wiki une traduction de preface.itely (surtout pour
le plaisir, en fait ;-)

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

à vous de relire, de corriger, et de valider s'il y a lieu.

Au passage, j'ai collé le fichier itely d'origine dans Smultron (je
suis sous Mac en ce moment) et j'ai bossé dessus dans l'éditeur avant
de le renvoyer sur le wiki ; ça me semble assez simple à faire, et
plus agréable que de rester dans son browser. Cependant, quand je
colle de long paragraphes, la balise <pre> du wiki affiche les lignes
d'un seul bloc, sans retour à la ligne... est-ce gênant ? y a-t-il un
moyen de casser automatiquement ses lignes ?

Cordialement,
Valentin.

---

From: "Valentin Villenave" <[email-masked]>
Date: Fri, 2 Feb 2007 18:04:46 +0100

> à vous de relire, de corriger, et de valider s'il y a lieu.

Merci à Ludovic pour les quelques changements dans la préface.

Une nouvelle question me taraude : je suis en train de poursuivre le
travail de Frédéric sur basic-notation.itely, et quand je regarde la
doc actuellement en ligne je trouve souvent des ajouts récents fait
par Graham, comme vous pourrez le voir sur
http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=history;f=Documentation/user/basic-notation.itely;h=da60b0e06cc876bc33edbfe50d74a0d53935c4be;hb=HEAD

D'un côté, je trouve ça super que le manuel soit mis à jour et
clarifié ; d'un autre côté c'est assez frustrant pour l'équipe de
traduction : que fait-on ? on mène d'abord à bien le fichier qu'on a,
ou bien on fait un diff au plus tôt pour essayer d'intégrer les ajouts
?

Pour tous ceux qui seraient interessés, la version sur laquelle je
travaille (qui est un gros morceau) se trouve sur
http://lilypondwiki.tuxfamily.org/index.php?title=Fr:basic-notation.itely

Cordialement,
Valentin.

---

From: Jean-Charles <[email-masked]>
Date: Fri, 02 Feb 2007 20:40:10 +0100

> ou bien on fait un diff au plus tôt pour essayer d'intégrer les ajouts

À mon humble avis, je crois qu'il est préférable d'adopter une démarche 
intellectuelle claire.

L'une des habitudes que j'avais, en fac de langues étrangères 
appliquées, consistait à maîtriser un texte, autrement dit se 
l'approprier, avant de le traduire. C'est plus facile si la version 
originelle est figée tout au long du processus de transposition.

Par ailleurs, le travail de relecture se complique pour un texte
« mouvant » où l'on risque de s'enliser au lieu de prendre du recul et 
agir à tête reposée.

Cet objectif de cohérence m'amène donc à opter pour une traduction menée 
à bien sur une version donnée et « validée » par plusieurs 
pseudo-correcteurs avant de prendre en compte et reporter les 
modifications de l'original.

C'était mon petit mot du jour...

@+
Jean-Charles

---

From: John Mandereau <[email-masked]>
Date: Fri, 02 Feb 2007 23:22:07 +0100

> à vous de relire, de corriger, et de valider s'il y a lieu.

Vu mon emploi du temsp chargé, j'ai du mal à suivre le rythme.
J'essaierai de regarder tout ça dimanche et de l'envoyer sur
git.sv.gnu.org si possible.  Au moins, si la typographie est correcte,
si le committish est bien indiqué et que la traduction a été vérifiée et
relue plusieurs fois, je serai 5 fois plus rapide pour le faire.

> moyen de casser automatiquement ses lignes ?

Les lignes ne devraient jamais dépasser 75 caractères ; de nombreux
éditeurs de texte ont une fontion "wordwrap" ou "retour à la ligne
automatique" qui non seulement affiche 75 caractères par ligne mais
modifie dans le fichier les retours chariots en conséquence.  Avec
Emacs, le plus pratique est de sélectionner le mode mineur auto-fill et
de corriger les retours charriots en faisant M-Q dans chaque paragraphe
qui en a besoin.

-- 
John Mandereau <[email-masked]>

---

From: John Mandereau <[email-masked]>
Date: Fri, 02 Feb 2007 23:27:47 +0100

> modifications de l'original.

C'est très bien dit.  Une bonne traduction ne peut se faire dans la
précipitation.  Il n'y a pas lieu de s'affoler parce qu'on traduit une
version pas tout à fait à jour, car le script check-translation pourra
toujours nous dire plus tard les changements, et si Graham se lance dans
la refonte complète d'une section, il nous prévient avant de le faire.

En quelques jours, le wiki semble avoir permis une avancée rapide des
traductions : c'est formidable, continuez ainsi !

---

From: Jean-Charles <[email-masked]>
Date: Mon, 05 Feb 2007 20:22:47 +0100

Le 01.02.2007 00:47, John Mandereau disait :
> Le mardi 30 janvier 2007 à 20:53 +0100, Jean-Charles a écrit :
>
>> John, est-il prévu un script du type check-translation pour la 
>> documentation aussi ?
> 
> C'est déjà fait, c'est justement ce qui m'a permis de vous envoyer
> récemment un patch de changements de la doc anglaise de 75 Ko !
> 
> Tu peux l'utiliser ainsi :
> 
> 1) crée les fichiers Makefile communs (--prefix=$HOME n'est pas
> indispensable mais utile si tu veux installer ta compilation de Lily
> dans ton $HOME) :
> 
> ./autogen.sh --prefix=$HOME

Ça me fait tout drôle de pouvoir à nouveau compiler LilyPond sans 
problème !..

./autogen.sh --prefix=/home/jcharles/GIT/Traducs

> Tu peux ignorer les erreurs de configure, du moment que la commande qui
> va suivre fonctionne ;-)
> 
./configure (j'ai compilé guile 1.8.1 pour continuer)
puis make  (8 mn) et make web (30 mn)

> 2) lance la vérification de la traduction proprement dite :
> 
> cd Documentation
> make ISOLANG=fr check-translation
> 
> Et voilà !
> 
> 
Pas glop !

[jcharles@localhost Documentation]$ make ISOLANG=fr check-translation
find fr/user/ -name '*.*tely' | xargs /usr/bin/python 
../buildscripts/check_translation.py ../buildscripts
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object 0d9d3feea8ca1b22388bd1c67545a518987e72f1
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object 94e27fe2da58c91791e1cacb32c16a4acccf0638
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object 64f0d86a7c0987b311bfdfdfeddfa063e1f2d6e7
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object 64f0d86a7c0987b311bfdfdfeddfa063e1f2d6e7
fatal: bad object 64f0d86a7c0987b311bfdfdfeddfa063e1f2d6e7
fatal: bad object 64f0d86a7c0987b311bfdfdfeddfa063e1f2d6e7
[jcharles@localhost Documentation]$

>>  Est-ce que je dois utiliser le dépôt master pour 
>> être sur la bonne version (raison pour laquelle je ne savais plus où 
>> j'en étais avec working.itely) ?
> 
> Il est important de suivre les 2 branches (stable/2.10 et master) de
> front, car pour l'instant les traductions se font sur la branche stable,
> et les mises à jour du manuel dans cette branche sont celles que je
> repique depuis la branche de développement.  Ensuite, quand la
> traduction du manuel est à jour dans la version stable, je reporte les
> changements de la doc française vers la branche de développement.  C'est
> un peu compliqué, mais ça se justifie : je n'ai aucun moyen de retarder
> les sorties de LilyPond, il est crucial que la traduction soir assez à
> jour (sinon les noms de page HTML ne correspondent pas et les fragments
> de partition n'apparaissent plus dans la traduction, et la doc de la
> branche de développement ne se compile pas toujours, et la prochaine
> version stable de LilyPond (2.12 ou 3.0) est encore loin, ainsi
> travailler sur la version stable me semble plus raisonnable.
> 

J'ai donc maintenant :
$HOME/GIT/lilypond -> master
$HOME/GIT/stable   -> stable/2.10

Ai-je bien appliqué ?

> Mais ce n'est pas grave si vous mettez un committish de la branche de
> développement dans une traduction, car si les 2 branches stable et
> master sont toutes les 2 sur votre dépôt Git, check-translation
> fonctionnera toujours aussi bien.
> 
> 
> Salutations lilyesques

---

From: "Valentin Villenave" <[email-masked]>
Date: Tue, 6 Feb 2007 16:01:07 +0100

Bonjour tout le monde,

j'ai traduit sur le Wiki le fichier putting.itely ; ceux qui veulent
peuvent le relire et y apporter leur corrections à
http://lilypondwiki.tuxfamily.org/index.php?title=Fr:putting.itely

J'ai pris soin d'y ajouter le commitish et les retours à la ligne ;-)

Ce qui nous donne, pour la traduction du manuel :

    *  Fr:Tutoriel (traduction mise à jour, en attente de relecture)

    * Fr:working.itely (traduction terminée, prêt à être envoyé sur le GIT)

    * Fr:preface.itely (traduction relue par Ludovic, prêt à être
envoyé sur le GIT ?)

    * Fr:putting.itely (traduction terminée, en attente de relecture)

    * Fr:basic-notation.itely (traduction achevée à 85%, en attente de
relecture)

Voilà. Je vous rappelle que je n'ai pas la possibilité d'envoyer tout
ça sur le git moi-même (j'attends encore qu'Acer ait le bon vouloir de
réparer mon ordinateur.) Si quelqu'un pouvait s'en charger après
relecture ce serait super...
À bientôt.

Valentin

---

From: John Mandereau <[email-masked]>
Date: Wed, 07 Feb 2007 00:08:22 +0100

>     * Fr:preface.itely (traduction relue par Ludovic, prêt à être

J'ai seulement relu la préface, j'avais déjà relu working.itely ; pour
le tutoriel, je te fais confiance ;-)  Je vais envoyer tout ça sur les
deux branches sur git.gnu.sv.org dès que les développeurs donnent leur
accord sur la refonte des scripts Python.  Tout ceci d'empêche pas que
vous continuiez à les relire en attendant, et même une fois qu'il sont
sur le dépôt Git.

>     * Fr:basic-notation.itely (traduction achevée à 85%, en attente de

Ces deux fichiers attendront d'être bien finis et relus.

Bien cordialement

---

From: John Mandereau <[email-masked]>
Date: Wed, 07 Feb 2007 00:21:57 +0100

> puis make  (8 mn) et make web (30 mn)

Waouh, ça dépote !  Sur mon Celeron M à 1,40 GHz, il y en a pour une
heure en tout.

> fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8

[snip]

> $HOME/GIT/stable   -> stable/2.10

Pas du tout.  Permets-moi quelques explications techniques.

Il faut avoir UN SEUL dépôt Git pour les deux branches, ce qui veut dire
que les deux branches (en fait les quatre : les 2 copies des branches
distantes de git.sv.gnu.org, appelées par exemples stable/2.10 et
master, et les 2 branches locales correspondantes, par exemple appelées
mystable et mymaster) sont dans le même répertoire .git (à la racine du
dépôt), et qu'une seule branche est visible à la fois.

Pour arriver à cela, il suffit de suivre des instructions semblables à
celles du myweb, sauf qu'on lance checkout et pull deux fois (une pour
chaque branche). "git checkout" (ou "cg switch") permet de passer de
l'une à l'autre branche, et "cg export ../toto" (je ne connais pas
d'équivalent git pur) permet d'exporter l'arborescence complète de la
révision courante dans le répoertoire ../toto pour pouvoir compiler tout
en continuant tranquillement à manipuler le dépôt Git.  Attention à
utiliser Git pull avec le nom de branche distante correspondant à la
branche courante !

Tout ce bazar permet de mettre n'importe quel committish de l'une ou de
l'autre branche, ce qui est assez souple.

En général, ne vous embêtez pas, travaillez tout le temps sur la branche
master, je m'occupe de la gymnastique pour reporter les changements sur
la branche stable.

---

From: Jean-Charles <[email-masked]>
Date: Wed, 07 Feb 2007 20:36:56 +0100

>    *  Fr:Tutoriel (traduction mise à jour, en attente de relecture)
Relu, pas de problème pour moi.
>    * Fr:working.itely (traduction terminée, prêt à être envoyé sur le GIT)
Quelques petites retouches effectuées sur le wiki
>    * Fr:preface.itely (traduction relue par Ludovic, prêt à être
idem
>    * Fr:putting.itely (traduction terminée, en attente de relecture)
Si ça peut attendre vendredi soir...
>    * Fr:basic-notation.itely (traduction achevée à 85%, en attente de
Pour vendredi ou samedi.

@+

Jean-Charles

---

From: John Mandereau <[email-masked]>
Date: Wed, 07 Feb 2007 23:33:51 +0100

>     *  Fr:Tutoriel (traduction mise à jour, en attente de relecture)

À la relecture de ce fichier, je dois rappeler qu'en Texinfo les espaces
insécables sont obtenus avec @tie{} entre 2 mots et sans espace, que
&nbsp; est r&éservé aux pages HTML.  Cependant, ce serait éreintant
d'ajouter des @tie{} avant chaque signe double de ponctutation, et
rendrait le texte source illisible, donc il vaut mieux dans ce cas
attendre que Texinfo gère ces cas automatiquement.

Par ailleurs, les blocs @lilypond dans le manuel doivent être des copies
EXACTES des extraits de la doc en anglais, exactes à l'espace et à la
chiure de mouche près.

Je m'occupe de corriger ça, comme je veux envoyer le tutoriel sur Git.

Bon courage pour les relectures à venir
-- 
John Mandereau <[email-masked]>

---

From: "Valentin Villenave" <[email-masked]>
Date: Thu, 8 Feb 2007 10:44:24 +0100

> EXACTES des extraits de la doc en anglais, exactes à l'espace et à la

C'est ennuyeux, car il y a parfois des indications textuelles, des
paroles, ou encore des noms de variables qui demanderaient vivement à
être traduits...

N'y a-t-il donc aucune possibilité de compiler les exemples LilyPond
du manuel français séparément de ceux du manuel anglais ?

Cordialement,
Valentin

---

From: "Valentin Villenave" <[email-masked]>
Date: Thu, 8 Feb 2007 12:31:08 +0100

Bonjour à tous

Bon, je continue hein...

J'ai terminé la traduction de basic-notation.itely sur le Wiki :
http://lilypondwiki.tuxfamily.org/index.php?title=Fr:basic-notation.itely

Elle attend patiemment vos propositions, corrections, amendements
etc., de même que putting.itely (et là John va râler car j'ai traduit
quelques trucs dans les exemples @lilypond...)

J'attire votre attention sur le fait que la première moitié de ce
fichier a été traduite par Frédéric ; il ne faudra donc pas l'oublier
dans la liste des contributeurs.

Je ne sais pas sur quelle version du fichier il est parti, je n'ai
donc pas pu ajouter de commitish (je crois que c'est une version qui
date de quelques mois, j'ai cru voir quelques changements depuis).

Quoiqu'il en soit, à l'heure actuelle, tous les fichiers dont John
avait fait la liste sont traduits et/ou relus. C'est peut-être le
moment de faire un point ? -- ou une bouffe, mais ça sera plus dur ;-)

Cordialement,
Valentin

---

From: John Mandereau <[email-masked]>
Date: Thu, 08 Feb 2007 23:11:16 +0100

> paroles, ou encore des noms de variables qui demanderaient vivement à

Je suis d'accord avec toi.

> du manuel français séparément de ceux du manuel anglais ?

Le problème n'est pas là.  Le fait est que lilypond-book traite les docs
traduites, mais sans compiler les extraits de musique avec LilyPond,
donc seules seront présentes les images de ceux qui se trouvent déjà
dans la doc en anglais.  Tu peux toujours t'amuser à bricoler les
makefiles pour changer ça, ou attendre que quelqu'un d'autre le fasse ;
je n'aurai pas le temps avant des semaines, sauf si je n'ai plus à
revoir les traductions avant de les envoyer sur git.sv.gnu.org.

---

From: John Mandereau <[email-masked]>
Date: Thu, 08 Feb 2007 23:54:40 +0100

> http://lilypondwiki.tuxfamily.org/index.php?title=Fr:basic-notation.itely

Super !  Tu as vraiment fait beaucoup en peu de temps sur les
traductions.

> quelques trucs dans les exemples @lilypond...)

Ce n'est pas grave si je râle ; par contre, comme je dispose de peu de
temps pour les traductions, l'envoi sur Git des traductions qui ne
passent pas les tests de contrôle qualité sera bloqué, jusqu'à ce que
tous les détails soient corrigés.

> date de quelques mois, j'ai cru voir quelques changements depuis).

La prochaine personne qui révise la traduction d'après la version la
plus récente de la branche master aura la responsabilité de mettre le
committish.

> moment de faire un point ? -- ou une bouffe, mais ça sera plus dur ;-)

Une bouffe, pourquoi pas ? :-)

Je me permets de faire le point.  La traduction du manuel avance bien,
et nous pouvons continuer ainsi.  J'aimerais simplement que plus de
traducteurs maîtrisent la technique, surtout Git et Texinfo, pour
assurer avec plus d'autonomie la mise à jour continuelle des
traductions.  Par ailleurs, une fois la traduction faite, il peut être
intéressant de critiquer et d'améliorer la documentation en elle-même.

Salutations lilyesques

---

From: Jean-Charles <[email-masked]>
Date: Fri, 09 Feb 2007 20:48:59 +0100

> attendre que Texinfo gère ces cas automatiquement.

Me basant sur la macro emacs que j'avais trouvé pour les accents en 
html, je viens de tester, avec succès et dans les deux sens, la bascule 
entre espace insécable et @tie{}. Pour la simple et bonne raison que les 
ponctuations à double caractères pourraient se retrouver en dehors de ce 
qui est compilé (commentaires, code lily etc.) une validation est 
nécessaire à chaque occurrence (y/n). On peut toujours sortir par C-g
Il suffit donc d'installer macros-tie.el dans le répertoire ~/site-lisp 
et de charger la macro en ajoutant au ~/.emacs une ligne :

;; transforme espace insécable dans texinfo et vice versa
(load "macros-tie")

D'autre-part, je viens de me rendre compte que la ligne de mode d'emacs 
m'indique la branche sur laquelle je travaille (master, myweb, 
web/master, mystable ...). Intéressant, non ?

> EXACTES des extraits de la doc en anglais, exactes à l'espace et à la

Tout à fait d'accord pour l'instant.

Je ferai ma lecture demain, en écoutant le rugby...

@+
Jean-Charles
;; tie-on : adapte la typographie francaise pour Texinfo
;; en matiere de ponctuation double (espace insecable avant).
;; Demande confirmation a chaque occurrence pour preserver
;; ces caracteres lorsqu'utilises dans des elements externes.
;; 

(defun tie-on ()
  (interactive)
  "change les espaces avant ;:!? et guillemets en @tie{}."
  (beginning-of-buffer)
  (query-replace " »" "@tie{}»:")
  (beginning-of-buffer)
  (query-replace "« " "«@tie{}")
  (beginning-of-buffer)
  (query-replace " :" "@tie{}:")
  (beginning-of-buffer)
  (query-replace " ?" "@tie{}?")
  (beginning-of-buffer)
  (query-replace " !" "@tie{}!")
  (beginning-of-buffer)
  (query-replace " ;" "@tie{};")
)

(defun tie-off ()
  (interactive)
  "change @tie{} en espaces avant ;:!? et guillemets."
  (beginning-of-buffer)
  (query-replace "@tie{}»" " »:")
  (beginning-of-buffer)
  (query-replace "«@tie{}" "« ")
  (beginning-of-buffer)
  (query-replace "@tie{}:" " :")
  (beginning-of-buffer)
  (query-replace "@tie{}?" " ?")
  (beginning-of-buffer)
  (query-replace "@tie{}!" " !")
  (beginning-of-buffer)
  (query-replace "@tie{};" " ;")
)

---

From: John Mandereau <[email-masked]>
Date: Sat, 10 Feb 2007 10:24:24 +0100

> ;; transforme espace insécable dans texinfo et vice versa

Je ne suis pas partisan de cette méthode : nous ne devrions pas avoir
besoin de nous prendre la tête avec une règle systématique comme
celle-ci, Texinfo devrait la gérer automatiquement.  Du reste, les
points d'interrogation et d'exclamation devraient être précédés d'une
espace fine (&thinsp; en HTML) et non d'une espace insécable normale
(&nbsp;).

Jean-Charles, je ne t'empêche pas de t'occuper de ça, mais en aucun cas
je perdrai mon temps à faire cela, je suis bien trop paresseux ! :-)
Par contre, je propose de prétraiter les fichiers Texinfo dans le
makefile avec sed, ce qui nous économiserait du temps et de l'énergie
une bonne fois pour toutes.

Bon week-end