Liste des fichiers en attente de relecture pour le noyau: 2.6.10 arch/v850/Kconfig arch/x86_64/Kconfig arch/x86_64/oprofile/Kconfig drivers/char/agp/Kconfig drivers/char/drm/Kconfig drivers/eisa/Kconfig drivers/fc4/Kconfig drivers/input/keyboard/Kconfig drivers/input/misc/Kconfig drivers/input/mouse/Kconfig drivers/input/serio/Kconfig drivers/input/touchscreen/Kconfig drivers/isdn/act2000/Kconfig drivers/media/dvb/cinergyT2/Kconfig drivers/media/dvb/dibusb/Kconfig drivers/media/dvb/frontends/Kconfig drivers/media/dvb/ttpci/Kconfig drivers/media/Kconfig drivers/net/appletalk/Kconfig drivers/net/arcnet/Kconfig drivers/net/arm/Kconfig drivers/net/hamradio/Kconfig drivers/net/irda/Kconfig drivers/net/pcmcia/Kconfig drivers/net/tokenring/Kconfig drivers/net/tulip/Kconfig drivers/pcmcia/Kconfig drivers/pnp/isapnp/Kconfig drivers/pnp/Kconfig drivers/usb/image/Kconfig drivers/usb/Kconfig drivers/zorro/Kconfig kernel/power/Kconfig net/llc/Kconfig net/xfrm/Kconfig sound/core/Kconfig sound/drivers/Kconfig
Liste des fichiers en attente de relecture pour le noyau: 2.6.11 arch/i386/kernel/cpu/cpufreq/Kconfig arch/x86_64/kernel/cpufreq/Kconfig drivers/cpufreq/Kconfig drivers/zorro/Kconfig
Liste des fichiers en attente de relecture pour le noyau: 2.6.12
Liste des fichiers en attente de relecture pour le noyau: 2.6.14
Liste des fichiers en attente de relecture pour le noyau: 2.6.15 block/Kconfig block/Kconfig.iosched drivers/scsi/pcmcia/Kconfig
Afficher les réponses par date
Gwenael, on voit que t'as repris le dessus depuis la petite déprime d'hier soir ;)
Maintenant, le top du top pour ton mail (ne tape pas sur la tête pliiiize) c'est de mettre en en-tête: -où on trouve la page du projet -comment on réserve -comment on fait après la relecture
Vu que cette info ne changera pas d'un mail à l'autre tu la mets en réserve qqpart et copy-paste dès que t'envoies un mail récapitulatif :)
Jean-Christophe
On 2006/05/31, at 6:55, gwenael@ordrejedis.net wrote:
Liste des fichiers en attente de relecture pour le noyau: 2.6.10
Suite au log de l'IRC quand je dormais:
Ca ne devrais pas poser de problèmes de zipper un fichier traduit, de l'attacher à un mail et de faire une demande de relecture publique sur une liste prévue pour ça.
On bosse dans des fichiers textes, compressés à un facteur de 30~40 (140ko->4ko). Et c'est plus immédiat pour un candidat relecteur d'avoir le fichier sous les yeux que d'avoir à aller le chercher sur un site (où le traducteur aura du le mettre en premier): on économise du temps (pas de commit du traducteur, pas de checkout du relecteur) et on est plus conviviaux.
Par ailleurs, si ça enquiquine des membres de la liste traduc@traduc de reçevoir une foultitude de mails on peut avoir la structure suivante:
•une page générale qui indique les procédures communes et les liens vers les pages projets
•une page par projet pour donner des indications sur l'état des lieux et les procédures spécifiques
•une liste de travail->envoi des demandes de trad, de relecteur avec fichiers attachés, liste utilisée exclusivement pour les propositions de participation et validations de relectures.
•une liste de discussion->discussions glossaires, discussions traductions problématiques issues de la liste de travail
_pas_ de liste par projet, ça ne sert qu'à isoler les participants et ça rajoute une "couche" de complication pour les débutants.
Jean-Christophe
On 2006/05/31, at 10:20, Jean-Christophe Helary wrote:
Gwenael, on voit que t'as repris le dessus depuis la petite déprime d'hier soir ;)
Maintenant, le top du top pour ton mail (ne tape pas sur la tête pliiiize) c'est de mettre en en-tête: -où on trouve la page du projet -comment on réserve -comment on fait après la relecture
Vu que cette info ne changera pas d'un mail à l'autre tu la mets en réserve qqpart et copy-paste dès que t'envoies un mail récapitulatif :)
Jean-Christophe
On 2006/05/31, at 6:55, gwenael@ordrejedis.net wrote:
Liste des fichiers en attente de relecture pour le noyau: 2.6.10
Le 2006-05-31 10:55:27 +0900, Jean-Christophe Helary écrivait :
Par ailleurs, si ça enquiquine des membres de la liste traduc@traduc de reçevoir une foultitude de mails on peut avoir la structure suivante:
Après une expérience pas très réussie avec le robot du projet de traduction GNU (qui est pourtant, à mon avis, un excellent outil), il nous a semblé que les robots un peu bavards devaient avoir leurs propres listes de diffusion. Ce qui a conduit à la création de la liste <traduc TIRET po CHEZ traduc POINT org>, qui est utilisée exclusivement pour les messages du robot.
Nous encourageons les différents projets à utiliser la liste <traduc CHEZ traduc POINT org> pour s'entraider, rechercher des traducteurs, des relecteurs, diffuser des annonces et essayer de trouver ensemble des solutions à des problèmes de traduction ou d'outils.
La liste peut accueillir des messages de robots, à conditions que ceux-ci soient en nombre limités.
Cependant, dans le cas de robots, il me semble préférable d'avoir des listes ciblées, par exemple par projet, afin que les personnes qui choisissent de s'y abonner puissent limiter ces abonnements à leurs centres d'intérêts.
?une page générale qui indique les procédures communes et les liens vers les pages projets
?une page par projet pour donner des indications sur l'état des lieux et les procédures spécifiques
C'est plus ou moins comme ça que nous sommes structurés. Cependant, il faut garder à l'esprit que l'association Traduc.org n'a rien de commun avec, par exemple, un projet comme le projet de traduction de Débian.
Traduc.org est un regroupement de projets de traduction, qui ont chacun leurs contraintes et qui ne sont pas forcément maîtres de leur organisation. Nous essayons de mettre en place des outils communs pour le bénéfice de tous, mais nous ne pouvons pas imposer à un projet sa façon de travailler.
Par contre, rien n'empêche de suggérer ou de proposer des solutions, que les différents projets pourront ou non adopter.
?une liste de travail->envoi des demandes de trad, de relecteur avec fichiers attachés, liste utilisée exclusivement pour les propositions de participation et validations de relectures.
?une liste de discussion->discussions glossaires, discussions traductions problématiques issues de la liste de travail
Jusqu'à présent, la liste <traduc CHEZ traduc POINT org> avait ces deux rôles.
La liste <glossaire CHEZ traduc POINT org> serait plutôt pour moi une liste à mettre en copie lors des discussions concernant la traduction de termes spécifiques, afin que les autres projets puissent se joindre à la discussion.
L'organisation du projet de glossaire n'étant pas encore totalement précisée, cette répartition est susceptible d'évoluer.
_pas_ de liste par projet, ça ne sert qu'à isoler les participants et ça rajoute une "couche" de complication pour les débutants.
Je vois deux bonnes raisons d'avoir des listes par projet :
- La principale est de permettre aux traducteurs de s'abonner en connaissance de cause aux courriers envoyés par tel ou tel robots, pour les robots produisant un certain volume de courrier.
- Pour des discussions internes à un projet et n'ayant rien à voir avec les traductions. Par exemple, une liste <traduc TIRET organisation CHEZ traduc POINT org>, à laquelle tout le monde peut s'abonner, est utilisée pour les détails de l'activité de l'association non liés aux traductions : organisation de la participation à des conférences, préparation d'assemblées générales, et cætera.
Mais en règle générale, nous encourageons les projets à utiliser la liste <traduc CHEZ traduc POINT org>.
Voilà.
Très bonne nuit.
Jean-Philippe,
Merci pour ces précisions importantes. Permet moi quelques commentaires:
On 2006/06/01, at 9:52, Jean-Philippe Guérard wrote:
Le 2006-05-31 10:55:27 +0900, Jean-Christophe Helary écrivait :
Par ailleurs, si ça enquiquine des membres de la liste traduc@traduc de reçevoir une foultitude de mails on peut avoir la structure suivante:
Après une expérience pas très réussie avec le robot du projet de traduction GNU (qui est pourtant, à mon avis, un excellent outil), il nous a semblé que les robots un peu bavards devaient avoir leurs propres listes de diffusion. Ce qui a conduit à la création de la liste <traduc TIRET po CHEZ traduc POINT org>, qui est utilisée exclusivement pour les messages du robot.
Nous encourageons les différents projets à utiliser la liste <traduc CHEZ traduc POINT org> pour s'entraider, rechercher des traducteurs, des relecteurs, diffuser des annonces et essayer de trouver ensemble des solutions à des problèmes de traduction ou d'outils.
La liste peut accueillir des messages de robots, à conditions que ceux-ci soient en nombre limités.
Cependant, dans le cas de robots, il me semble préférable d'avoir des listes ciblées, par exemple par projet, afin que les personnes qui choisissent de s'y abonner puissent limiter ces abonnements à leurs centres d'intérêts.
Dans l'ensemble je pense que ce que tu décris est très proche de ce que j'imaginais. En ce qui concerne les robots, moi non-plus ça ne m'intéresse pas de les avoir sous le nez à chaque instant. Mais un message récapitulatif de l'état du projet, diffusé mensuellement sur "traduc chez traduc" avec des informations générées automatiquement mais pertinentes permettrai une émulation et un rapprochement des "équipes" il me semble.
?une page générale qui indique les procédures communes et les liens vers les pages projets
?une page par projet pour donner des indications sur l'état des lieux et les procédures spécifiques
C'est plus ou moins comme ça que nous sommes structurés. Cependant, il faut garder à l'esprit que l'association Traduc.org n'a rien de commun avec, par exemple, un projet comme le projet de traduction de Débian.
J'en suis tout à fait conscient. J'espère qu'il n'y a pas eu de confusions à ce sujet. Je ne proposais pas de copier Debian-l10n-fr mais d'adapter des méthodes éprouvées à un fonctionnement différent.
Traduc.org est un regroupement de projets de traduction, qui ont chacun leurs contraintes et qui ne sont pas forcément maîtres de leur organisation. Nous essayons de mettre en place des outils communs pour le bénéfice de tous, mais nous ne pouvons pas imposer à un projet sa façon de travailler.
Par contre, rien n'empêche de suggérer ou de proposer des solutions, que les différents projets pourront ou non adopter.
Je n'avais absolument pas conscience de cet aspect "fédération de projets". Toutes mes excuses pour la confusion qui en découle.
Il me semble que pour faciliter la tâche des potentiels bénévoles, il est tout de même important de tenter d'uniformiser ce qui est uniformisable. C'est un peu comme un traducteur qui doit s'adapter aux méthodes de chaque nouvelle agence de traduction qui lui propose des travaux. En tant que traducteur, les tâches sont similaires et le résultat est formalisé mais l'interfaçage demande des efforts (mêmes minimes) qui ne devraient pas exister.
?une liste de travail->envoi des demandes de trad, de relecteur avec fichiers attachés, liste utilisée exclusivement pour les propositions de participation et validations de relectures.
?une liste de discussion->discussions glossaires, discussions traductions problématiques issues de la liste de travail
Jusqu'à présent, la liste <traduc CHEZ traduc POINT org> avait ces deux rôles.
La liste <glossaire CHEZ traduc POINT org> serait plutôt pour moi une liste à mettre en copie lors des discussions concernant la traduction de termes spécifiques, afin que les autres projets puissent se joindre à la discussion.
L'organisation du projet de glossaire n'étant pas encore totalement précisée, cette répartition est susceptible d'évoluer.
Je vois.
_pas_ de liste par projet, ça ne sert qu'à isoler les participants et ça rajoute une "couche" de complication pour les débutants.
Je vois deux bonnes raisons d'avoir des listes par projet :
- La principale est de permettre aux traducteurs de s'abonner en connaissance de cause aux courriers envoyés par tel ou tel robots, pour les robots produisant un certain volume de courrier.
S'il s'agit de listes robotisées il serait préférable de l'indiquer. Il me semble peu fructueux que les efforts et les échanges soient dispersés sur plusieurs listes, "traduc chez traduc" pourrait utiliser un système de drapeaux pour identifier les projets discutés et ça créerait de l'émulation, les listes robotisées étant là pour donner une information à sens unique.
- Pour des discussions internes à un projet et n'ayant rien à voir
avec les traductions. Par exemple, une liste <traduc TIRET organisation CHEZ traduc POINT org>, à laquelle tout le monde peut s'abonner, est utilisée pour les détails de l'activité de l'association non liés aux traductions : organisation de la participation à des conférences, préparation d'assemblées générales, et cætera.
Je ne considérai pas "traduc tiret organisation" comme une liste- projet en elle même, mais comme une "méta-liste". Mais je partage ton point de vue.
Mais en règle générale, nous encourageons les projets à utiliser la liste <traduc CHEZ traduc POINT org>.
Merci encore pour ces précisions. Cordialement,
Jean-Christophe
Jean-Christophe Helary a écrit :
Gwenael, on voit que t'as repris le dessus depuis la petite déprime d'hier soir ;)
Maintenant, le top du top pour ton mail (ne tape pas sur la tête pliiiize) c'est de mettre en en-tête:
Le top du top, c'est que l'on arrete les questions débile, et une vrai reflexion...
-où on trouve la page du projet
TOUJOURS AU MEME ENDROIT ... http://kernelfr.traduc.org parce que bon, je vois pas trop l'interet de le mettre dans le mail, qui sera dans la liste kernelfr-user
-comment on réserve
Comme d'habitude, et ca ne changera pas... il y a une interface il faut l'utiliser ...
-comment on fait après la relecture
commen d'habitude encore une fois... je vais pas me répéter.
Vu que cette info ne changera pas d'un mail à l'autre tu la mets en réserve qqpart et copy-paste dès que t'envoies un mail récapitulatif :)
heureusement que c'est pas moi qui fait le mail... merci petit KernelFRbot :p
Jean-Christophe
Gwenael Pellen
On 2006/05/31, at 19:00, Gwenael Pellen wrote:
Vu que cette info ne changera pas d'un mail à l'autre tu la mets en réserve qqpart et copy-paste dès que t'envoies un mail récapitulatif :)
heureusement que c'est pas moi qui fait le mail... merci petit KernelFRbot :p
Et ben si c'est pas toi qui fait le mail t'as encore moins de raisons de ne pas mettre les infos que j'ai indiquées.
Par ailleurs, limiter ton envoi sur la liste kernel, c'est contreproductif, si c'est un rapport mensuel que tu envoies il n'y a aucune raison de ne pas l'envoyer à tout le monde. Ça peut intéresser d'autres personnes. Il ne faut pas s'étonner si les projets ont si peu de volontaires si les annonces sont faites sur les listes de chaque projets...
Jean-Christophe
Le Mardi 30 Mai 2006 23:55, gwenael@ordrejedis.net a écrit :
Liste des fichiers en attente de relecture pour le noyau: 2.6.10
arch/v850/Kconfig
(...)
Bonjour à tous !
Excusez-moi de m'immiscer, mais je suis assez surpris que ce, ô combien utile projet de traduction du noyau concerne des versions déjà anciennes.
Si je ne m'abuse, les explications de configuration du noyau sont assez stables dans le temps. Il devrait donc y avoir moyen avec un genre de "diff" de trouver facilement les fichiers modifiés dans les nouvelles versions.
À ce moment, lors de chaque nouvelle version du noyau, il faudrait créer un nouveau référentiel de traduction, et y injecter tout ce qui n'a pas été modifié depuis la version précédente.
En effet, autant j'aimerais avoir sous la main une traduction du nouveau noyau avant de le configurer, autant je m'imagine mal configurer un 2.6.10.
Pour faciliter le processus de mise à jour (et ainsi, injecter dans la nouvelle version toutes les modifications), il semble, en effet, que po4a serait un bon outil.
Je me trompe ?
A+
Pour faciliter le processus de mise à jour (et ainsi, injecter dans la nouvelle version toutes les modifications), il semble, en effet, que po4a serait un bon outil.
Pour tous les documents existant dont le statut est incertain, on peut faire des diffs et voire le résultat. Moi, quand je suis confronté à ce genre de problèmes je fais la chose suivante (ça a l'air plus galère, mais au final c'est plus intuitif):
-je prends les fichiers correspondant à une version, d'un coté l'anglais de l'autre le français -je m'assure que les fichiers on des lignes qui correspondent -je fusione les 2 fichiers pour en faire une mémoire de traduction (TMX) -j'injecte ça dans OmegaT (ou n'importe quel outil qui accepte le standard TMX) -je charge le fichier à traduire -OmegaT me donne automatiquement les parties non traduites. -la traduction finie, je stocke la TMX finale pour la prchaine mise à jour (avoir des correspondance sur des parties déjà traduites permet aussi d'assure une cohérence de style)
Dans le cadre du projet emacs, c'est un peu comme ça que j'ai envie de faire.
1-voir le statut des documents présents 2-les fichiers non mis à jours sont traités comme indiqué + haut avec la version correspondante de l'original 3-ils sont mis à jours 4-les fichiers non-traduits bénéficient des TMX ainsi créées pour s'accorder sur le style si nécessaire.
Jean-Christophe
Gérard Delafond a écrit :
Le Mardi 30 Mai 2006 23:55, gwenael@ordrejedis.net a écrit :
Liste des fichiers en attente de relecture pour le noyau: 2.6.10
arch/v850/Kconfig
(...)
Bonjour à tous !
Excusez-moi de m'immiscer, mais je suis assez surpris que ce, ô combien utile projet de traduction du noyau concerne des versions déjà anciennes.
Si je ne m'abuse, les explications de configuration du noyau sont assez stables dans le temps.
assez stable, ne veut pas dire totalement stable...
Il devrait donc y avoir moyen avec un genre de "diff" de trouver facilement les fichiers modifiés dans les nouvelles versions.
j'avais fais un robot... qui n'est jamais allé au dela du test.
À ce moment, lors de chaque nouvelle version du noyau, il faudrait créer un nouveau référentiel de traduction, et y injecter tout ce qui n'a pas été modifié depuis la version précédente.
En effet, autant j'aimerais avoir sous la main une traduction du nouveau noyau avant de le configurer, autant je m'imagine mal configurer un 2.6.10.
Certains sont obligés de faire des downgrades parce que le pilote du matériel X n'est pas pris en charge par la super dernière version du noyau...
Pour faciliter le processus de mise à jour (et ainsi, injecter dans la nouvelle version toutes les modifications), il semble, en effet, que po4a serait un bon outil.
Je me trompe ?
A+
mon robot fesait un md5sum entre un vielle version et une version plus récente. si les md5sum sont égaux alors les fichiers sont identiques donc il faut regardé s'il est valide, si oui alors copy / paste dans la nouvelle branche. sinon s'il est traduit alors copy / paste dans la nouvelle branche. sinon rien faire...
Le seul problème était que je ne modifiais pas les status des fichiers...
afin bref c'etait pas encore au point.
Salut,
Le mercredi 31 mai 2006 à 22:34 +0200, Gwenael Pellen a écrit :
Gérard Delafond a écrit :
[...]
Il devrait donc y avoir moyen avec un genre de "diff" de trouver facilement les fichiers modifiés dans les nouvelles versions.
j'avais fais un robot... qui n'est jamais allé au dela du test.
[...]
Pour faciliter le processus de mise à jour (et ainsi, injecter dans la nouvelle version toutes les modifications), il semble, en effet, que po4a serait un bon outil.
Je me trompe ?
A+
mon robot fesait un md5sum entre un vielle version et une version plus récente. si les md5sum sont égaux alors les fichiers sont identiques donc il faut regardé s'il est valide, si oui alors copy / paste dans la nouvelle branche. sinon s'il est traduit alors copy / paste dans la nouvelle branche. sinon rien faire...
Le seul problème était que je ne modifiais pas les status des fichiers...
Je suis tenté de vous indiquer po4a.
http://po4a.alioth.debian.org/
Mes 2¢
-
Gwenael Pellen -
gwenael＠ordrejedis.net
-
Gérard Delafond -
Jean-Christophe Helary -
Jean-Philippe Guérard -
Pierre Machard