traduction de "working"

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

working.itely (21.2 KB)

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

working.itely (21.2 KB)

···

2007/1/23, Ludovic Sardain <****@****>:

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

_______________________________________________
liste de diffusion lilypond-user-fr
lilypond-user-fr@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user-fr

Le 23.01.2007 16:52, Ludovic Sardain disait :

Bonjour à tous,

je viens de finir le premier jet de la traudction du fichier "working.itely".

Je vous la livre en pièce jointe pour relecture. Veuillez s'il vous
plaît faire vos corrections directement sur le fichier et le renvoyer,
ou encore mieux, donner le résultat de la commande diff -u
ancienfichier fichiercorrigé

Bonsoir,
Ci-joint un différentiel sur le fichier de Valentin.

Une phrase, ligne 35, ne me plaît cependant pas vraiment.

« Cependant, il y a quelques considérations à prendre
en compte lorsque l'on écrit un fichier LilyPond. »

Je comprends à la lecture de la version originale
« However, there are a few other things to consider when writing lilypond files. » qu'il est bon d'adopter certaines pratiques lorsque l'on écrit des fichiers LilyPond. Je n'ai pas trouvé de traduction élégante pour retranscrire ce conseil-truc-habitude-à-prendre;

@+
Jean-Charles

working.itely.diff (15.4 KB)

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.

working.itely (21.2 KB)

···

2007/1/23, Jean-Charles <****@****>:

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

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

···

2007/1/24, Valentin Villenave <****@****>:

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.

Le 23.01.2007 16:52, Ludovic Sardain disait :

Bonjour à tous,

je viens de finir le premier jet de la traudction du fichier "working.itely".

Je vous la livre en pièce jointe pour relecture. Veuillez s'il vous
plaît faire vos corrections directement sur le fichier et le renvoyer,
ou encore mieux, donner le résultat de la commande diff -u
ancienfichier fichiercorrigé

à bientôt

Ludovic

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

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

working.itely.new (21.2 KB)

working.itely.diff (17.6 KB)

···

2007/1/24, Valentin Villenave <****@****>:

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 # :frowning:
Merci
JJR.

···

--
Jean-Jacques Rétorré

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

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

working.itely.diff (2.79 KB)

working.itely.new (21.8 KB)

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 ? :wink:

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

···

Le jeudi 25 janvier 2007 à 09:49 +0100, Jean-Yves Baudais a écrit :

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 ?

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

Bonjour,

John Mandereau a écrit :

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.

   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.diff (5.39 KB)

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ô ? :wink:

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

···

2007/1/25, Valentin Villenave <****@****>:

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.

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

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.

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.

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.

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

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

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

···

Le vendredi 26 janvier 2007 à 10:12 +0100, Valentin Villenave a écrit :

2007/1/25, Valentin Villenave <****@****>:

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

Bonjour,

John Mandereau a écrit :
> 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.

   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

En lisant les archives :slight_smile:

(j'ai comme l'impression que ça n'existe pas un fichier en tant que
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
de ne pas m'envoyer la réponse à mon adresse perso, mais seulement à la
liste (comme je suis abonné...;-).

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
lilypond-user-fr@gnu.org est dans le champ À ou Cc vers le dossier
lily-fr.

Salutations lilypondesques

···

Le vendredi 26 janvier 2007 à 09:24 +0100, Jean-Yves Baudais a écrit :
--
John Mandereau <****@****>

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

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

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

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

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

···

2007/1/27, John Mandereau <****@****>:

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

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.

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.

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.

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

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.

···

Le samedi 27 janvier 2007 à 21:40 +0100, Valentin Villenave a écrit :

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