Re: mise à jour des traducs du manuel de l'utili sateur

[Jean-Charles]

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 !

address@hidden 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
address@hidden 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