[Bug 1329794] New: F24-L10N-FR-Suivi des problèmes
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1329794
Bug ID: 1329794
Summary: F24-L10N-FR-Suivi des problèmes
Product: Fedora Localization
Component: French [fr]
Assignee: pablomg+fedora(a)eskapa.be
Reporter: jb.holcroft(a)gmail.com
QA Contact: trans-fr(a)lists.fedoraproject.org
CC: michael.ughetto(a)gmail.com, pablomg+fedora(a)eskapa.be
This ticket is a tracking bug.
Ce ticket vise à centraliser les anomalies que nous avons détecté dans la
traduction de F24 et que nous souhaiterions voir corrigées.
--
You are receiving this mail because:
You are the QA Contact for the bug.
6 years, 2 months
Projet de traduction des descriptions des logiciels dans la logithèque
by Jean-Baptiste
Bonjour,
j'aimerais vous proposer un projet, à minima francophone, idéalement
multilingue : traduire titre et description des logiciels dans le
magasin d'applications GNOME-Logiciels.
L'idée est de rendre plus accessible l'ensemble de la logithèque mise à
disposition par la communauté Fedora.
Pour se faire : chaque projet doit posséder un fichier [appdata] (le nom
de la norme freedesktop est appstream), et celui ci doit être inclus
dans l'empaquetage rpm de celui-ci.
D'ailleurs, la [traduction de ces fichiers] est prévue dans cette
spécification.
Comme il y a des milliers de logiciels, cette tâche simple devient tout
de suite plus compliquée en termes de coordination et de suivi.
En termes de processus :
* il faut remonter jusqu'au projet source
* trouver son lieu de traduction (peut être une plateforme de
traduction, un logiciel dédié ou même simplement par fichier)
* demander d'inclure cette traduction dans les nouvelles versions du
logiciel (voire demander d'en publier une)
* demander aux mainteneurs du rpm d'inclure le fichier appdata dans leur
[empaquetage]
Quelle source de données ?
Richard Hughes, un des développeurs de GNOME-Softwares produit avec son
outil [appstream-glib], une série d'[extractions xml] sur lesquelles
nous pouvons mesurer notre avancement.
Pour information, il y a quelques mois j'avais produit quelques
[statistiques] (à l'époque sur 613 paquets F23, nous avions 28% des
logiciels de la catégorie "desktop" dont les descriptions étaient
traduites et 18% si on prend toutes les catégories de logiciels (il y a
aussi des extensions, des polices de caractère, des pilotes, etc.).
Je recherche actuellement une solution logicielle permettant de générer
facilement un tableau de bord montrant l'avancement, et permettant de
saisir des liens vers les tickets de suivi.
Si quelqu'un sait faire quelque chose de simple et d'automatique cela
serait génial.
L'objet de ce projet n'est pas d'augmenter la quantité de projets dans
la logithèque (ajout des appdata), mais de traduire ceux ayant déjà
présents.
Il ne s'agit pas non plus de traduire tous les logiciels disponibles,
mais de faciliter leur accessibilité en rendant compréhensible /
recherchable leurs descriptions.
Si l'un amène l'autre, c'est très bien, mais ce n'est pas l'objectif
principal (je pense cependant que cela permettra d'augmenter le besoin
de traduction de certains).
Voilà pour la présentation, maintenant il faut en discuter et itérer
collectivement :
* le projet et son approche vous semblent-t-ils bien pertinents ?
* avez-vous envie de voir ce projet réussir en donnant un coup de main ?
[appdata]
https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html
[traduction des fichiers]
https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Trans...
[empaquetage] https://fedoraproject.org/wiki/Packaging:AppData
[appstream-glib] https://github.com/hughsie/appstream-glib
[extractions xml] https://alt.fedoraproject.org/pub/alt/screenshots/f24/
[statistiques]
https://fedoraproject.org/wiki/User:Jibecfed#AppData_.2F_AppStream_Statis...
NB : désolé, j'ai envoyé hier ce message sur la liste internationale au
lieu de la francophone
--
Jean-Baptiste Holcroft
7 years, 9 months
Mes propositions de modification de nos processus
by José Fournier
Chers amis de Fedora trans-fr,
Voilà maintenant trois mois que j'ai rejoint l'équipe de traduction de
Fedora et je ne le regrette pas tant l'ambiance ici me paraît bonne et
constructive. Mais, peut -être est-il temps pour moi de m'exprimer sur
ce début d'expérience.
Je commencerais ici par le positif. Je l'ai déjà dit dans mon
auto-présentation initiale, j'ai été longtemps traducteur chez Gentoo et
j'ai quitté Gentoo non pas par mécontentement, bien au contraire, mais
parce que leur distribution était un peu difficile à gérer au jour le
jour pour le non informaticien que je suis. Gentoo n'est pas une
distribution « Grand Public » mais est plutôt une distribution adaptée
aux développeurs. Je ne sais pas si je serai contredit mais c'est mon
opinion. C'est parce que j'ai retrouvé chez Fedora les mêmes qualités, à
la fois dans la distribution et dans la rigueur de l'organisation que
je l'ai rejointe. J'ai fait de brefs passages chez Arch, openSuse et
Ubuntu et je n'en dirais pas la même chose, même si fondamentalement je
garde aussi beaucoup d'estime pour les gens qui s'impliquent dans ces
distributions avec la même conviction et le même désir d'apporter leur
pierre à l'édifice.
Concernant les équipes, on retrouve chez Gentoo comme chez Fedora la
même organisation très bien structurée, la même volonté commune d'écoute
réciproque – ce qui n'exclut pas les conflits de point de vue – et le
même désir de voir progresser la distribution vers une toujours plus
grande stabilité, une toujours plus grande facilité d'utilisation et une
toujours plus grande richesse d'offre.
Je ne connais pas suffisamment le fonctionnement des autres équipes de
Fedora pour en parler, aussi limiterai-je mon propos à ce qui concerne
l'équipe de traduction française.
S'agissant donc de l'implication des personnes, de leur compétence, de
leur volonté de bien faire, il n'y a guère de différences. Là où les
choses commencent à différer, c'est en termes d'efficacité, c'est à dire
du rendement des efforts produits. Il convient cependant, toujours en ce
qui concerne les processus de traduction, de distinguer trois domaines.
Celui de la localisation des programmes, celui de la traduction du wiki,
et celui de la traduction des documentations de fond – les guides ou
manuels par exemple.
Du côté de la localisation des programmes les choses me semblent bien se
passer. Les appels à la mobilisation sont suivis d'effets et la date
butoir de libération de la nouvelle version agit comme un catalyseur
auprès de tous. Sur ce sujet, donc un grand bravo. Dans ce domaine, les
choses sont difficiles à comparer avec Gentoo qui est une « rolling
distribution ».
Du côté de la traduction du wiki, il n'y a rien de particulier à dire si
ce n'est le fait qu'il y a très peu de mécanismes de verrouillage et de
contrôle. Beaucoup repose sur le respect par le traducteur de certaines
règles de comportement telles que prévenir lorsqu'il a traduit ou
corrigé une page ou signaler une page désuète ou contestable. Ce mode de
fonctionnement se traduit par une efficacité maximum, les modifications
et les traductions étant rendues immédiatement disponibles, quitte à
être remises en question par la suite.
Pour finir, du côté de la traduction de la documentation, les choses me
semblent être très différentes et, force est de constater que le
rendement – il s'agit toujours du rapport entre les efforts produits et
le résultat effectif – est, au risque de vous choquer, assez faible. Ne
pas rendre un document traduit depuis des semaines, voire des mois – je
ne parle pas seulement ici de mon propre travail et je dis cela sans
acrimonie ni arrière-pensées – accessible à son auditoire est assez
regrettable, voire inacceptable. Inacceptable, parce que c'est une bien
maigre reconnaissance du travail du traducteur que de ne pas le faire et
qu'il n'y a rien de plus décourageant. Inacceptable aussi parce que
c'est en priver les lecteurs potentiels et donc, en cela, détourner des
utilisateurs tout aussi potentiels de Fedora. On peut donc légitimement
s'interroger sur ce qui ne va pas et je laisse à chacun le soin de le
faire et d'apporter son point de vue.
Pour ma part, je n'irai pas chercher l'explication dans le comportement
ou la compétence des uns et des autres. Non, tous les acteurs ici sont
des bénévoles compétents qui font les efforts qu'ils peuvent – parfois
certainement au détriment d'autres aspects de leur vie privée – et rien
ne peut et ne doit leur être reproché. Que cela soit clair entre-nous.
Je vois plutôt la raison de cette inefficacité, à la fois dans le
processus de traduction validation et dans le système de valeurs qui,
implicitement, l'accompagne. Je suis trop nouveau pour dire comment ce
système de valeurs a pu se mettre en place, toujours est-il qu'il est là
et qu'il faut bien en parler.
Chez Gentoo, lorsque je traduisais un manuel, ce dernier était mis en
ligne quelques heures après tout simplement. Si des anomalies étaient
détectées par la suite, elles étaient signalées et corrigées tout
simplement.
Chez Fedora, ou du moins chez Fedora FR, les choses se passent
différemment. Le document traduit doit d'abord être validé. Soit. Je ne
suis pas contre le principe, sauf que validation ne doit pas signifier
« paralysie ». De deux choses l'une, soit on a les moyens de notre
politique, soit on ne l'a pas.
1- Si on a les moyens de cette politique, on doit se donner un délai –
un délai de quinze jours me paraitrait raisonnable. Passé ce délai le
document devrait être considéré comme validé et proposé à la publication.
2- Si on n'a pas les moyens de notre politique, alors il faut
l'abandonner, ou alors, il faut arrêter de traduire.
Comme manifestement nous nous inscrivons dans la deuxième hypothèse,
c'est à dire que nombre des traducteurs/relecteurs inscrits sur notre
liste sont trop accaparés par d'autres tâches, il convient peut-être de
revoir notre principe de fonctionnement.
Je propose le fonctionnement suivant :
A- Dans le délai de quinze jours, les relecteurs font leur travail,
corrigent les anomalies de forme ou mineures, soumettent à la discussion
des traductions qui ne leur semblent pas convenir (les règles proposées
par Jean-Baptiste dans sa dernière relance sur le guide d'installation
me semblent bonnes).
B- Comme le délai est court, on pourrait instituer une procédure de
révision, par exemple un mois après la publication, ou permanente, ce
qui laisserait largement le temps de se mettre d'accord sur certains
points difficiles.
C- Un droit d'opposition à la publication d'une traduction fantaisiste
avec un nombre significatif d'exemples concrets qui montreraient que le
traducteur n'a manifestement pas compris de quoi il retournait. La
décision de publier ou de ne pas publier dans ce cas serait collégiale.
D- On pourrait aussi réfléchir à la mise en place de guides
partiellement traduits. C'est parfois le cas pour les logiciels, alors
pourquoi ne pas instaurer une traduction chapitre par chapitre – les
chapitres non traduits, ou les chapitres dont la traduction est très
contestée, continuant d'apparaître en anglais. Cela éviterait les
à-coups de charge et rendrait les choses plus fluides.
Comme vous le voyez, ce principe est à l'inverse du fonctionnement
actuel. Une traduction n'a plus à démontrer qu'elle est admissible,
c'est à celui qui la conteste d'apporter la preuve qu'elle ne l'est pas.
C'est à celui qui conteste une traduction, non pas parce qu'elle est
fausse mais simplement parce qu'elle peut être améliorée – d'emporter
l'adhésion des autres ; mais en aucun cas une traduction imparfaite
quant au style – tout en restant juste sur le fond – ne doit bloquer la
publication. Le processus de relecture doit être un processus
d'amélioration de la qualité, pas un processus de blocage, c'est
pourquoi sa durée doit être limitée.
Si je parlais de système de valeurs tout à l'heure, c'est parce que je
crois en déceler un, pas forcément exprimé, mais sous-jacent. Il
pourrait, en forçant un peu le trait, se résumer ainsi : « ce qui n'est
pas parfait n'a pas droit de cité ». Ce principe de recherche de la
perfection, ou du moins de tendance vers la perfection, est acceptable
en soi, mais il ne doit pas conduire à la paralysie ou au blocage. Nous
n'atteindrons jamais la perfection. Nous nous en rapprocherons
seulement. Ce qui importe c'est de capitaliser et de ne jamais nous en
éloigner, en communicant sur ce qui ne va pas, en mettant en place une
base de connaissance etc.
À mon sens, il est plus souhaitable que le lecteur dispose d'une
traduction imparfaite – à condition qu'elle ne soit pas aberrante et ne
l'induise pas en erreur – plutôt que pas de traduction du tout.
Voila, c'était certainement un peu long mais j'avais envie de vous dire
ces choses là. J'espère que mon propos sera compris et pris pour ce
qu'il est : « une simple proposition ».
Bien à vous
José
7 years, 10 months
À propos du processus de relecture
by Jean-Baptiste
Bonjour,
Nous venons de faire une semaine de relecture que je considère comme étant un succès pour son résultat, mais peu efficace en termes d'outillage.
J'ai personnellement choisi d'imprimer le document et le corriger au stylo. Puis de télécharger l'ensemble des fichiers pour trouver où faire ma modification (via grep dans le dossier).
Nous avons un guide d'installation dont la relecture est toujours en attente. Mais sur un document si large, c'est d'autant plus complexe.
Nous discutons de façon saine sur les règles générales à appliquer, mais pour le reste, devoir tout réécrire me semble chronophage au possible.
Pouvons nous essayer l'annotation collaborative d'un pdf puis se répartir l'application des modifications ?
tout ce qui est mineur serait reporté dans ce document.
Il faudra peut être aussi noter différemment les corrections à apporter globalement, versionner les pdf pour ne pas perdre les annotations à chaque reproduction du document, synchroniser les corrections.
Connaissez vous un outil libre qui permette de faire ça ? Pensez vous intéressant d'essayer cette méthode ?
--
Jean-Baptiste
7 years, 10 months
Construction du livre
by José Fournier
Jean-Bapstiste,
Je ne sais pas si tu as lu le rapport d'anomalie. J'ai réussi à trouver
un palliatif pour l'espace fine insécable et le ć. Mais une autre
anomalie, qui n'a rien à voir semble se présenter : c'est la non prise
en compte de certains messages traduits, p. ex. dans Aperçu. Au début,
il n'y avait qu'un message, puis il y en a de plus en plus. J'ai retapé
les deux messages de la section Aperçu intégralement dans Zanata, pour
être sûr qu'ils n'étaient pas mal formés, mais ça continue.
Avant de remplir un nouveau rapport d'anomalie, j'aimerais savoir si tu
rencontres le même problème.
La procédure en bref:
Dans un dossier p. ex. RN-pub
git clone -b <BRANCH> https://pagure.io/release-note
cd release-note
publican trans_drop
publican update_pot
publican build --formats=html,html-single,pdf --langs=fr
Dans un autre dossier p. ex. RN-Zanata
Télécharger le fichier de configuration puis
zanata-cli pull --pull-type both
Remplacer les po de RN-pub/release-note/fr par ceux de NN-Zanata/fr/pot/
Construire
publican build --formats=html,pdf --langs=fr
Le résultat est dans tmp/fr
7 years, 10 months
GA General Availability
by José Fournier
Je me demande si pour « general availability » on ne pourrait pas écrire
« GA (version finale) ».
Ça permet de conserver la relation avec GA tout en disant que c'est la
version finale.
7 years, 10 months