Le Mon, 20 Oct 2008 23:29:40 +0200,
Gauthier Ancelin <gauthier.ancelin(a)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.