[Fedora-trans-fr] Organisation pour traduire les specspo

[Martin-Gomez Pablo]

Le Mon, 20 Oct 2008 23:29:40 +0200,
Gauthier Ancelin <gauthier.ancelin at laposte.net> a écrit :

> 
> Le Monday 20 October 2008 17:35:48 Florent Le Coz, vous avez écrit :
> > Bonjour à tous,
> >
> > voilà, comme la traduction des modules touche à sa fin, il va
> > falloir se tourner vers le reste (la doc, etc)
Effectivement, pour l'heure, je dirais qu'il y a priorité au site web
et aux différentes docs.
> >
> > A côté de ça, il y a les specspo, qui ne semblent pas être
> > primordiaux, mais moi je trouve ça important (c'est quand même
> > important que les francophones comprennent ce qu'ils installent
> > (j'irai même jusqu'à dire que je trouve ça plus important que les
> > Release Notes)).
> 
> J'avoue que je n'ai toujours pas compris cet engouement pour les
> release notes, elles intéressent surtout un public "pointu", qui
> généralement comprend bien l'anglais.
> 
Je vais un peu expliquer mon point de vue sur les relnotes : À
l'origine, elles ont été traduites pour F9 parce que quelques personnes
avaient trouvé dommage de pas avoir celle de F8 en français; c'est
vrai que ça n'a pas vraiment déchaîné les foules mais c'est surtout dû
à un manque d'annonce (et aussi peut-être par un manque d'intérêt).
Donc pour moi, cet engouement est plus symbolique, dans le sens où
une communauté montre sa maturité (en terme de traduction) à travers la
traduction des releases notes. Enfin, c'est mon avis personnel.

> > Je me demandais donc si on ne pouvait pas faire ça comme un
> > "fil-rouge", en parallèle des autres traductions plus
> > "urgentes" (surtout que les specspo, ça change tout le temps).
> >
> > Je suis personnellement assez motivé pour traduire ces trucs, mais
> > y'en a des tonnes (plus de 6000 descriptions (et elles sont pas
> > courtes)), donc faudrait s'organiser pour traduire ça de façon
> > régulière. Je pense aussi qu'une traduction parfaite n'est pas
> > primordiale, contrairement aux traductions des différents modules,
> > et qu'on pourrait éviter de perdre trop de temps sur la relecture
> > (sans pour autant bâcler tout ça)
> 
> Le problème c'est que c'est quand même une vitrine, quelque part, il
> ne faut pas négliger la qualité de la traduction.
> 
> Pour la taille, j'avais pris l'habitude de ne traduire que les
> chaînes en rapport avec autre chose que des outils ou des
> bibliothèques pour développeurs. Eux, ils parlent anglais, ils n'en
> ont pas un besoin urgent. Du coup, ça diminue sérieusement le nombre
> de chaînes à traduire (division par 3 ou 4).
Ça me paraît effectivement clair que les chaînes en relation avec le
développement ne sont pas du tout une priorité.
> 
> Il y a aussi quelques travaux urgents, comme changer les termes
> "paquetages" en "paquets", ça peut se faire une fois les fuzzy
> résolus (pour éviter de perdre la trace des fuzzy justement). Mais
> des fuzzy, rien que sur desc, il y en a 1200...
Je ne trouve pas que c'est tellement urgent que ça, je l'aurais plutôt
vu comme les finitions. Enfin, en soit ça ne prend pas beaucoup de
temps. 
> 
> >
> > On pourrait par exemple se répartir ça sur 4 personnes :
> > deux personnes sur les summary (chacun traduit genre 30 (nombre au
> > pif) labels, puis on relit et corrige les 30 qu'a fait l'autre, et
> > on commit, et on recommence), et deux autres qui font les desc (et
> > même chose)
> >
> > Je propose pas ça pour tenter de faire avancer les choses, je ne
> > sais pas du tout quelles sont vos habitudes et je ne me permettrais
> > pas de vous imposer mes idées, ce ne sont que de simples
> > propositions. J'attends donc vos avis là-dessus :-) (genre si c'est
> > pourri, dites le ;-))
> 
> Je n'aime pas trop les traductions d'un même paquetage par
> différentes personnes, chacun a ses termes favoris, et je trouve que
> la qualité s'en ressent (sauf à utiliser un dictionnaire de
> traduction, mais c'est lourd à mettre en place).
> 
> Mais ça peut se faire à deux : un qui traduit toujours le même
> paquetage, l'autre qui le relit, et réciproquement. Attention au
> volume de desc : il est beaucoup plus gros que summary, bien que le
> nombre de chaînes ne soit pas très différent.
Au vu des relnotes de F9, un fichier traduit par deux personnes ne sont
pas particulièrement différent et généralement après une
interrelecture, c'est ni-vu ni-connu.
> 
> Je pense surtout qu'il faudrait travailler au corps les dév. pour
> qu'ils mettent fin à ces monstres. Je verrais plutôt un fichier par
> thème (outils de dév C/C++, outils Java, bureautique, graphisme,
> etc...) qui contienne chacun les chaînes de summary et de desc
> actuelles pour ce thème. On pourrait ainsi s'attaquer aux thèmes
> prioritaires (bureautique, outils internet par exemple) et laisser de
> côté les outils de dév, pour plus tard si on a le temps.
Effectivement, ce serait une idée d'avoir un specspo divisé par
comps.xml. Faudrait le proposer upstream (à savoir où ?)
> 
> De mon côté, en ce moment, je n'ai justement absolument pas de temps
> à consacrer à tout ça, hélas. C'était juste mon opinion...
Pour l'instant, c'est pas du tout urgent, d'ailleurs les statistiques
de specspo sont désactivées.
> 
> Gauthier.
>