J'ai traduit en ligne les fichiers correspondant au chapitre X86-*. Je me suis décidé à tester le système, même si je considère qu'il occulte la vue d'ensemble du récit du Guide. Donc, comme je n'ai pas relu à partir du chargement global du git, il se peut qu'il y ait des incohérences, en particulier dans les phrases titres de paragraphe ou de chapitre où l'on ne sait pas s'il faut utiliser l'impératif ou l'infinitif. Le gentil relecteur sera donc attentif à cette particularité. C'est la même chose pour l'emploi du singulier ou du pluriel selon le contexte.
Par contre, c'est un travail de programmation internet remarquable qui permet la sauvegarde immédiate de son travail et évite les erreurs de manipulation entre fichiers. Le vérificateur intégré est utile, mais je le trouve un peu tatillon: il rouspète si j'ajoute une traduction entre parenthèses! La suggestion des phrases ressemblantes est utile.
A+ Gé
Le 27/04/2013 22:51, "Gérard - g.mail" a écrit :
J'ai traduit en ligne les fichiers correspondant au chapitre X86-*. Je me suis décidé à tester le système, même si je considère qu'il occulte la vue d'ensemble du récit du Guide. Donc, comme je n'ai pas relu à partir du chargement global du git, il se peut qu'il y ait des incohérences, en particulier dans les phrases titres de paragraphe ou de chapitre où l'on ne sait pas s'il faut utiliser l'impératif ou l'infinitif. Le gentil relecteur sera donc attentif à cette particularité. C'est la même chose pour l'emploi du singulier ou du pluriel selon le contexte.
Bravo ! L'un des avantages de traduire en ligne est de suivre le mantra du libre : release often, release early. Et ça évite les effets tunnel.
Pour les problèmes de contexte, certains logiciels peuvent avoir des remarques glissées dans le code pour l'expliquer. Mais ça n'est pas forcément le cas pour les documents.
Pour la relecture, j'ai ma petite idée. À creuser avant de vous en parler. L'idée serait de se retrouver et de faire ça ensemble. Sauf personne n'est au même endroit.
Par contre, c'est un travail de programmation internet remarquable qui permet la sauvegarde immédiate de son travail et évite les erreurs de manipulation entre fichiers. Le vérificateur intégré est utile, mais je le trouve un peu tatillon: il rouspète si j'ajoute une traduction entre parenthèses! La suggestion des phrases ressemblantes est utile.
Il y a même pire. Si dans le texte il y a « 100% sure », et que tu traduis par « 100% certain », il refusera catégoriquement de prendre ta traduction. Motif : le paramètre %s (% s...ure) n'est pas retrouvé dans la chaîne traduite.
J'ai ouvert le ticket suivant : https://github.com/transifex/transifex/issues/219
Il a été fermé dans la foulée comme n'étant pas un bug, mais je ne suis pas du tout convaincu. À creuser notamment sur la notation du « % » dans gettext... À doubler ou pas ?
Au moins, sur les parenthèses, il râle, mais fait le boulot quand même.
De mon côté, j'avance pas mal sur les derniers contenus de fedora-main : - setroubleshoot est terminé - Policycoreutils est en très bonne voie. L'avantage est qu'un paquet de chaînes de ce dernier est à peu de choses près présent dans le premier.
Pour ces deux-là, je ne traduis pas directement en ligne, mais utilise le logiciel Lokalize qui a l'avantage de pouvoir travailler sur des corpus importants, lorsque Lotte les limite aux seuls partages de mémoires de traduction configurés par les gestionnaires des documents.
Cordialement, bonne continuation à tous,
Jérôme
PS : pour info, le Français était redescendu à la 3e place sur les avancements de traduction après l'Espagnol et le Japonais, nous sommes à nouveau en seconde place, et dans 300 chaînes, à la première. Ce qui permettra aussi de se poser un peu, et de faire comme les hongrois : relire massivement en ligne tout ce qui a été traduit jusque maintenant, mais relire vraiment. J'ai fait le test il y a quelques semaines sur anaconda, ça se fait bien, et permet de trouver des perles. Et si on n'est pas sûr, on laisse non validé/non relu, et on demande à d'autres d'aider : tout est ligne, donc facile à trouver.
Le 27/04/2013 23:50, Jérôme Fenal a écrit :
Il y a même pire. Si dans le texte il y a « 100% sure », et que tu traduis par « 100% certain », il refusera catégoriquement de prendre ta traduction. Motif : le paramètre %s (% s...ure) n'est pas retrouvé dans la chaîne traduite.
J'ai ouvert le ticket suivant : https://github.com/transifex/transifex/issues/219
Il a été fermé dans la foulée comme n'étant pas un bug, mais je ne suis pas du tout convaincu. À creuser notamment sur la notation du « % » dans gettext... À doubler ou pas ?
Désolé de te confirmer qu'il n'y a pas bug. Le signe % dans Docbook (utilisé par publican pour générer les pages web) est un marqueur d'entité, tu ne peux pas l'écrire directement de manière brute. Il faut que tu l'écrives % avec l'esperluette, le code et le point virgule. Donc si tu écris, « 100 % certain », je suis sûr que cela passe comme une lettre à la poste et tu liras « 100 % certain » dans la page web.
Je parle bien sûr des traductions de Guides.
A+ Gé
Le dimanche 28 avril 2013 à 00:34:05 (+0200), "Gérard - g.mail" a écrit :
Le 27/04/2013 23:50, Jérôme Fenal a écrit :
Il y a même pire. Si dans le texte il y a « 100% sure », et que tu traduis par « 100% certain », il refusera catégoriquement de prendre ta traduction. Motif : le paramètre %s (% s...ure) n'est pas retrouvé dans la chaîne traduite.
J'ai ouvert le ticket suivant : https://github.com/transifex/transifex/issues/219
Il a été fermé dans la foulée comme n'étant pas un bug, mais je ne suis pas du tout convaincu. À creuser notamment sur la notation du « % » dans gettext... À doubler ou pas ?
Désolé de te confirmer qu'il n'y a pas bug. Le signe % dans Docbook (utilisé par publican pour générer les pages web) est un marqueur d'entité, tu ne peux pas l'écrire directement de manière brute. Il faut que tu l'écrives % avec l'esperluette, le code et le point virgule. Donc si tu écris, « 100 % certain », je suis sûr que cela passe comme une lettre à la poste et tu liras « 100 % certain » dans la page web.
Le standard Gettext, si mes souvenirs sont bon, échappe le « % » en le doublant. Transifex est développé au plus près du standard, et donc indique l'erreur. Gérard, tu as très certainement raison, mais l'erreur initiale vient probablement des sources. Nous ne devrions pas à modifier le codage des traductions. Après, si Docbook n'interprète pas correctement le %% pour génerer le POT (ou la traduction avec les PO), et bien peut-être que l'éditeur de la documentation devrait lui saisir « % » au lieu du signe lui-même. Il me semble que % devrait être précédé d'une espace insécable fine, et donc le « » n'est pas tout à fait juste dans l'exemple, mais c'est un autre détail.
Je parle bien sûr des traductions de Guides.
Jérôme, j'attire l'attention sur le problème de modification du codage. J'ai corrigé de nombreux code HTML dans les sites internet.. Nous utilisons Genshi, qui échape le code lui même. Donc si dans l'originale tu as « Attention: », et que tu traduis par « Attention : », le code sera échappé (& remplacé par &) et donc l'effet attendu sera incorrect.
Le 28/04/2013 11:56, Kévin Raymond a écrit :
Le dimanche 28 avril 2013 à 00:34:05 (+0200), "Gérard - g.mail" a écrit :
Le 27/04/2013 23:50, Jérôme Fenal a écrit :
Il y a même pire. Si dans le texte il y a « 100% sure », et que tu traduis par « 100% certain », il refusera catégoriquement de prendre ta traduction. Motif : le paramètre %s (% s...ure) n'est pas retrouvé dans la chaîne traduite.
J'ai ouvert le ticket suivant : https://github.com/transifex/transifex/issues/219
Il a été fermé dans la foulée comme n'étant pas un bug, mais je ne suis pas du tout convaincu. À creuser notamment sur la notation du « % » dans gettext... À doubler ou pas ?
Désolé de te confirmer qu'il n'y a pas bug. Le signe % dans Docbook (utilisé par publican pour générer les pages web) est un marqueur d'entité, tu ne peux pas l'écrire directement de manière brute. Il faut que tu l'écrives % avec l'esperluette, le code et le point virgule. Donc si tu écris, « 100 % certain », je suis sûr que cela passe comme une lettre à la poste et tu liras « 100 % certain » dans la page web.
OK, je vais donc remonter ces points, si je me souviens de là où je les ai vu. J'en ai au moins un dans le ticket ;)
Le standard Gettext, si mes souvenirs sont bon, échappe le « % » en le doublant. Transifex est développé au plus près du standard, et donc indique l'erreur. Gérard, tu as très certainement raison, mais l'erreur initiale vient probablement des sources. Nous ne devrions pas à modifier le codage des traductions. Après, si Docbook n'interprète pas correctement le %% pour génerer le POT (ou la traduction avec les PO), et bien peut-être que l'éditeur de la documentation devrait lui saisir « % » au lieu du signe lui-même. Il me semble que % devrait être précédé d'une espace insécable fine, et donc le « » n'est pas tout à fait juste dans l'exemple, mais c'est un autre détail.
Je parle bien sûr des traductions de Guides.
Jérôme, j'attire l'attention sur le problème de modification du codage. J'ai corrigé de nombreux code HTML dans les sites internet.. Nous utilisons Genshi, qui échape le code lui même. Donc si dans l'originale tu as « Attention: », et que tu traduis par « Attention : », le code sera échappé (& remplacé par &) et donc l'effet attendu sera incorrect.
Yup, tu m'avais déjà dit. Et comme Firefox honore maintenant les nbsp, et Transifex/Lotte aussi, je ne fais plus que ça ;)
Cdt,
J.
Le samedi 27 avril 2013 à 23:50:20 (+0200), Jérôme Fenal a écrit :
L'un des avantages de traduire en ligne est de suivre le mantra du libre : release often, release early. Et ça évite les effets tunnel.
Oui enfin, on a aussi la main sur la publication. Lorsqu'on décide qu'un guide est publiable dans notre langue, on peut ouvrir un ticket et demander une publication (j'ai aussi les droits, à une époque je le faisais bien plus régulièrement…)
[snip]
Pour la relecture, j'ai ma petite idée. À creuser avant de vous en parler. L'idée serait de se retrouver et de faire ça ensemble. Sauf personne n'est au même endroit.
Déjà, niveau coordination on (l'équipe) pourrait convenir d'une réunion IRC à certains moments clés (tel que « 3 semaines avant publication ») histoire qu'on partage nos efforts correctement. Bien sûr, certain d'entre vous n'ont pas besoin qu'on mette en avant ce qu'il faut faire, ce n'est qu'une idée. On pourrait avoir une réunion préparant la traduction finale des logiciels (fedora-main) puis une seconde préparant la publication des guides (donc pendant la phase beta).
[snip]
J'ai ouvert le ticket suivant : https://github.com/transifex/transifex/issues/219
Mon commentaire prochainnement.
De mon côté, j'avance pas mal sur les derniers contenus de fedora-main :
- setroubleshoot est terminé
En même temps, je trouve dommage qu'on ai à traduire des messages d'erreur. C'est comme les API, ça ne devrait pas se retrouver dans les POT. Enfin, ce n'est pas vraiment à nous, traducteurs, de définir ce qui est un message d'erreur et ce qui est véritablement l'application.
- Policycoreutils est en très bonne voie. L'avantage est qu'un
paquet de chaînes de ce dernier est à peu de choses près présent dans le premier.
Pour ces deux-là, je ne traduis pas directement en ligne, mais utilise le logiciel Lokalize qui a l'avantage de pouvoir travailler sur des corpus importants, lorsque Lotte les limite aux seuls partages de mémoires de traduction configurés par les gestionnaires des documents.
Il y a yum par exemple, qui est difficile de traduire en ligne. En effet, le nombre d'espace définit l'alignement de la sortie du logiciel, et donc, il faut compter nos caractères un par un. C'est bien plus pratique avec un éditeur de texte à chasse fixe.
PS : pour info, le Français était redescendu à la 3e place sur les avancements de traduction après l'Espagnol et le Japonais, nous sommes à nouveau en seconde place, et dans 300 chaînes, à la première.
Oui j'ai vu ça, ils sont vraiment allé vite pour nous remonter. Mais l'objectif n'est pas le 100 % traduit, mais plutôt le maximum avec 0 % d'erreurs :)
Ce qui permettra aussi de se poser un peu, et de faire comme les hongrois : relire massivement en ligne tout ce qui a été traduit jusque maintenant, mais relire vraiment. J'ai fait le test il y a quelques semaines sur anaconda, ça se fait bien, et permet de trouver des perles. Et si on n'est pas sûr, on laisse non validé/non relu, et on demande à d'autres d'aider : tout est ligne, donc facile à trouver.
Je me dois de rebondire là-dessus. Nous n'avons toujours pas de « relecteurs » officiels. On en a parlé à un moment donné, on avait un début de liste et une définition de comment passer relecteur, il serait peut-être temps de s'y remettre. Mais : - il y a de nombreux logiciels dont la traduction ne bouge plus depuis des années, ils ont normalement été relus hors ligne ; - il y a des logiciels dont la traduction évolue sans cesse, ce devrait peut-être être notre priorité (c'est le cas de la documentation) ; - la relecture n'est utile qu'au traducteurs, les mainteneurs n'en tiennent toujours pas compte (et ça ne va pas changer rapidement).
Le 28/04/2013 11:49, Kévin Raymond a écrit :
Le samedi 27 avril 2013 à 23:50:20 (+0200), Jérôme Fenal a écrit :
L'un des avantages de traduire en ligne est de suivre le mantra du libre : release often, release early. Et ça évite les effets tunnel.
Oui enfin, on a aussi la main sur la publication. Lorsqu'on décide qu'un guide est publiable dans notre langue, on peut ouvrir un ticket et demander une publication (j'ai aussi les droits, à une époque je le faisais bien plus régulièrement…)
Certes, mais c'est bien aussi d'avoir de l'actualité, et permet de ne pas travailler tout seul, ce qui n'est pas forcément toujours gratifiant.
[snip]
Pour la relecture, j'ai ma petite idée. À creuser avant de vous en parler. L'idée serait de se retrouver et de faire ça ensemble. Sauf personne n'est au même endroit.
Déjà, niveau coordination on (l'équipe) pourrait convenir d'une réunion IRC à certains moments clés (tel que « 3 semaines avant publication ») histoire qu'on partage nos efforts correctement. Bien sûr, certain d'entre vous n'ont pas besoin qu'on mette en avant ce qu'il faut faire, ce n'est qu'une idée. On pourrait avoir une réunion préparant la traduction finale des logiciels (fedora-main) puis une seconde préparant la publication des guides (donc pendant la phase beta).
Ça peut effectivement être un bon début.
[...]
Pour ces deux-là, je ne traduis pas directement en ligne, mais utilise le logiciel Lokalize qui a l'avantage de pouvoir travailler sur des corpus importants, lorsque Lotte les limite aux seuls partages de mémoires de traduction configurés par les gestionnaires des documents.
Il y a yum par exemple, qui est difficile de traduire en ligne. En effet, le nombre d'espace définit l'alignement de la sortie du logiciel, et donc, il faut compter nos caractères un par un. C'est bien plus pratique avec un éditeur de texte à chasse fixe.
Si c'est en début de ligne, ce n'est pas un problème. Si c'est au milieu, alors là oui.
PS : pour info, le Français était redescendu à la 3e place sur les avancements de traduction après l'Espagnol et le Japonais, nous sommes à nouveau en seconde place, et dans 300 chaînes, à la première.
Oui j'ai vu ça, ils sont vraiment allé vite pour nous remonter. Mais l'objectif n'est pas le 100 % traduit, mais plutôt le maximum avec 0 % d'erreurs :)
Les deux vont ensembles. Et c'est aussi un moyen de motiver les troupes : « regardez, votre travail fait avancer tout le monde ».
Ce qui permettra aussi de se poser un peu, et de faire comme les hongrois : relire massivement en ligne tout ce qui a été traduit jusque maintenant, mais relire vraiment. J'ai fait le test il y a quelques semaines sur anaconda, ça se fait bien, et permet de trouver des perles. Et si on n'est pas sûr, on laisse non validé/non relu, et on demande à d'autres d'aider : tout est ligne, donc facile à trouver.
Je me dois de rebondire là-dessus. Nous n'avons toujours pas de « relecteurs » officiels. On en a parlé à un moment donné, on avait un début de liste et une définition de comment passer relecteur, il serait peut-être temps de s'y remettre. Mais :
- il y a de nombreux logiciels dont la traduction ne bouge plus depuis des années, ils ont normalement été relus hors ligne ;
Sais-tu les identifier ?
- il y a des logiciels dont la traduction évolue sans cesse, ce devrait peut-être être notre priorité (c'est le cas de la documentation) ;
Oui.
- la relecture n'est utile qu'au traducteurs, les mainteneurs n'en tiennent toujours pas compte (et ça ne va pas changer rapidement).
Là, je ne suis pas complètement d'accord.
La relecture nous sert aussi à savoir où nous en sommes dans le processus de traduction/relecture, et surtout d'en avoir une trace. Cf. ma question ci-dessus sur les logiciels qui ne bougent plus.
Et dans notre processus de publication sur les documentations, la fin d'une relecture peut être le déclencheur d'une publication.
Cdt,
J.
Le 27/04/2013 23:50, Jérôme Fenal a écrit :
Le 27/04/2013 22:51, "Gérard - g.mail" a écrit :
J'ai traduit en ligne les fichiers correspondant au chapitre X86-*. Je me suis décidé à tester le système, même si je considère qu'il occulte la vue d'ensemble du récit du Guide. Donc, comme je n'ai pas relu à partir du chargement global du git, il se peut qu'il y ait des incohérences, en particulier dans les phrases titres de paragraphe ou de chapitre où l'on ne sait pas s'il faut utiliser l'impératif ou l'infinitif. Le gentil relecteur sera donc attentif à cette particularité. C'est la même chose pour l'emploi du singulier ou du pluriel selon le contexte.
Bravo ! L'un des avantages de traduire en ligne est de suivre le mantra du libre : release often, release early. Et ça évite les effets tunnel.
Pour les problèmes de contexte, certains logiciels peuvent avoir des remarques glissées dans le code pour l'expliquer. Mais ça n'est pas forcément le cas pour les documents.
Pour la relecture, j'ai ma petite idée. À creuser avant de vous en parler. L'idée serait de se retrouver et de faire ça ensemble. Sauf personne n'est au même endroit.
Par contre, c'est un travail de programmation internet remarquable qui permet la sauvegarde immédiate de son travail et évite les erreurs de manipulation entre fichiers. Le vérificateur intégré est utile, mais je le trouve un peu tatillon: il rouspète si j'ajoute une traduction entre parenthèses! La suggestion des phrases ressemblantes est utile.
Il y a même pire. Si dans le texte il y a « 100% sure », et que tu traduis par « 100% certain », il refusera catégoriquement de prendre ta traduction. Motif : le paramètre %s (% s...ure) n'est pas retrouvé dans la chaîne traduite.
J'ai ouvert le ticket suivant : https://github.com/transifex/transifex/issues/219
Il a été fermé dans la foulée comme n'étant pas un bug, mais je ne suis pas du tout convaincu. À creuser notamment sur la notation du « % » dans gettext... À doubler ou pas ?
Au moins, sur les parenthèses, il râle, mais fait le boulot quand même.
De mon côté, j'avance pas mal sur les derniers contenus de fedora-main :
- setroubleshoot est terminé
- Policycoreutils est en très bonne voie. L'avantage est qu'un paquet
de chaînes de ce dernier est à peu de choses près présent dans le premier.
Pour ces deux-là, je ne traduis pas directement en ligne, mais utilise le logiciel Lokalize qui a l'avantage de pouvoir travailler sur des corpus importants, lorsque Lotte les limite aux seuls partages de mémoires de traduction configurés par les gestionnaires des documents.
Cordialement, bonne continuation à tous,
Jérôme
PS : pour info, le Français était redescendu à la 3e place sur les avancements de traduction après l'Espagnol et le Japonais, nous sommes à nouveau en seconde place, et dans 300 chaînes, à la première. Ce qui permettra aussi de se poser un peu, et de faire comme les hongrois : relire massivement en ligne tout ce qui a été traduit jusque maintenant, mais relire vraiment. J'ai fait le test il y a quelques semaines sur anaconda, ça se fait bien, et permet de trouver des perles. Et si on n'est pas sûr, on laisse non validé/non relu, et on demande à d'autres d'aider : tout est ligne, donc facile à trouver. -- trans-fr mailing list trans-fr@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans-fr
Je ne partage pas ton enthousiasme pour Lotte. Outre l'effet tunnel, et les vérifications tatillonnes, je viens de remonter un bug à propos du drag and drop en fin de phrase. Mais il est vrai que l'outil n'en est qu'à ses débuts. Il rouspète pour les parenthèses, mais ne prend pas en compte les espaces insécables, fines ou pas. Il faut écrire (ou   pour une demi fine insécable si je me souviens bien) et si on fait une faute de frappe comme cela m'est arrivé publican envoie sur les roses et comme il n'indique pas le nom du fichier fautif, il faut jouer aux Sherlock Holmes! D'autres traducteurs modifient les balises Docbook, involontairement j'espère, mais cela est bloquant aussi.
En résumé, je vais reprendre ma méthode avec git et publican, et gtranlator (bogué mais simple), mais dès que j'aurai traduit un fichier (ou une partie de fichier) je téléverserai le plus rapidement possible, promis! A+ Gé
Le 28/04/2013 12:20, "Gérard - g.mail" a écrit : [...
Je ne partage pas ton enthousiasme pour Lotte. Outre l'effet tunnel, et les vérifications tatillonnes, je viens de remonter un bug à propos du drag and drop en fin de phrase.
J'ai vu ton anomalie (pour une raison qui m'échappe, je reçois maintenant toutes les anomalies de transifex sur github).
Je pense que ton problème vient du fait que l'application ne reçoit pas d'événement clavier ou de modification de TEXT/TEXTAREA HTML. Le tirer/lâcher, si c'est comme la copie de tampon à la souris sous X11, ne doit pas en générer, donc l'application ne sait pas que ça a été modifié. Si tu tapes une espace, que tu la supprimes ensuite, ça devrait fonctionner. Sauf si ma compréhension de la chose est la mauvaise.
Mais il est vrai que l'outil n'en est qu'à ses débuts. Il rouspète pour les parenthèses, mais ne prend pas en compte les espaces insécables, fines ou pas. Il faut écrire (ou   pour une demi fine insécable si je me souviens bien) et si on fait une faute de frappe comme cela m'est arrivé publican envoie sur les roses et comme il n'indique pas le nom du fichier fautif, il faut jouer aux Sherlock Holmes! D'autres traducteurs modifient les balises Docbook, involontairement j'espère, mais cela est bloquant aussi.
La prise en compte des insécables fonctionne chez moi avec Firefox 17 ESR sur RHEL6. J'ai ouvert un ticket pour faire comme Zanata : surligner une insécable avec un fond de couleur différent, comme dans Lokalize, mais aussi comme Zanata le fait en mode web.
Je n'ai pas essayé sur un autre OS, ni avec Chrome sur Linux.
En résumé, je vais reprendre ma méthode avec git et publican, et gtranlator (bogué mais simple), mais dès que j'aurai traduit un fichier (ou une partie de fichier) je téléverserai le plus rapidement possible, promis!
Merci pour ton travail de titan en tout cas !
Jérôme
trans-fr@lists.fedoraproject.org
-
Gérard - g.mail -
Jérôme Fenal -
Kévin Raymond