mise à jour des traducs du manuel de l'utilisateur

John_Mandereau · Février 2, 2007, 10:22

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.

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.

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 ?

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.

···

Le vendredi 02 février 2007 à 12:12 +0100, Valentin Villenave a écrit :

--
John Mandereau <****@****>

John_Mandereau · Février 2, 2007, 10:27

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 !

···

Le vendredi 02 février 2007 à 20:40 +0100, Jean-Charles a écrit :

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

--
John Mandereau <****@****>

Jean-Charles1 · Février 5, 2007, 7:22

Le 01.02.2007 00:47, John Mandereau disait :

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 0d9d3feea8ca1b22388bd1c67545a518987e72f1
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object 94e27fe2da58c91791e1cacb32c16a4acccf0638
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
fatal: bad object 64f0d86a7c0987b311bfdfdfeddfa063e1f2d6e7
fatal: bad object ac7d0e72b32b6a11470f598f2bee180b11402fe8
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é ?

···

Le mardi 30 janvier 2007 à 20:53 +0100, Jean-Charles a écrit :

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

Valentin_Villenave · Février 6, 2007, 3:01

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

John_Mandereau · Février 6, 2007, 11:08

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 ?)

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:putting.itely (traduction terminée, en attente de relecture)

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

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

Bien cordialement

···

Le mardi 06 février 2007 à 16:01 +0100, Valentin Villenave a écrit :
--
John Mandereau <****@****>

John_Mandereau · Février 6, 2007, 11:21

./configure (j'ai compilé guile 1.8.1 pour continuer)
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.

> 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

[snip]

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

Ai-je bien appliqué ?

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.

···

Le lundi 05 février 2007 à 20:22 +0100, Jean-Charles a écrit :

--
John Mandereau <****@****>

Jean-Charles1 · Février 7, 2007, 7:36

Le 06.02.2007 16:01, Valentin Villenave disait :

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)

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
envoyé sur le GIT ?)

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
relecture)

Pour vendredi ou samedi.

@+

Jean-Charles

John_Mandereau · Février 7, 2007, 10:33

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

···

Le mardi 06 février 2007 à 16:01 +0100, Valentin Villenave a écrit :

Ce qui nous donne, pour la traduction du manuel :

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

--
John Mandereau <****@****>

Valentin_Villenave · Février 8, 2007, 9:44

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

···

Le 07/02/07, John Mandereau<****@****> a écrit :

Le mardi 06 février 2007 à 16:01 +0100, Valentin Villenave a écrit :

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.

Valentin_Villenave · Février 8, 2007, 11:31

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

John_Mandereau · Février 8, 2007, 10:11

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

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

Je suis d'accord avec toi.

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 ?

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.

···

Le jeudi 08 février 2007 à 10:44 +0100, Valentin Villenave a écrit :

Le 07/02/07, John Mandereau<****@****> a écrit :

--
John Mandereau <****@****>

John_Mandereau · Février 8, 2007, 10:54

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

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

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

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.

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

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.

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

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

···

Le jeudi 08 février 2007 à 12:31 +0100, Valentin Villenave a écrit :
--
John Mandereau <****@****>

Jean-Charles1 · Février 9, 2007, 7:48

Le 07.02.2007 23:33, John Mandereau disait :

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

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 ?

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.

Tout à fait d'accord pour l'instant.

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

@+
Jean-Charles

macros-tie.el (1.14 KB)

John_Mandereau · Février 10, 2007, 9:24

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 (  en HTML) et non d'une espace insécable normale
( ).

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

···

Le vendredi 09 février 2007 à 20:48 +0100, Jean-Charles a écrit :

Le 07.02.2007 23:33, John Mandereau disait :
> À 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
>   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.

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")

--
John Mandereau <****@****>