Ah merci!!!! Je préviens les auteurs pour transiflex, et je veux bien prendre un (petit) morceau a traduire.
Claude Envoyé de mon iPhone > Le 10 sept. 2014 à 00:04, Martin Quinson <[email protected]> a écrit : > > Un message court pour dire que ca juste marche (cf ce que powerpoint > donne à Gilbert qui a toutes les polices), on va traduire dans > transiflex dans le confort de traduction, et la mise en page après > coup sera minime (si on laisse de coté les captures d'écran à refaire). > > Le processus à suivre est donc ici: > https://github.com/mquinson/CreativeComputing-FR/tree/master/powerpoint > > Je m'occupe de faire le projet transiflex dès que possible, mais ca > risque de me prendre encore une bonne semaine vu mon EDT. Si quelqu'un > veut se lancer à l'assaut de transiflex, qu'il n'hésite pas. > > La taille des fragments, c'est le bloc de texte dans powerpoint. > > J'ai pas d'action transiflex, mais une fois bien configuré, il > télécharge l'original sous forme .po depuis un git, et commite le > travail des traducteurs au même format au même endroit. On est donc > libre de sortir quand on veut, et on gagne sur bcp de tableaux. On > peut utiliser pootle (mais faut l'héberger) ou launchpad (mais faut > utiliser bzr plutot que git), osef un peu pour l'instant. Il est temps > de traduire. > > > TODO list: > - découper le ppt en fichiers séparés, un par unité (qui veut) > - passer la moulinette pour extraire les chaines (je fais) > - ouvrir un projet transiflex qui permette de traduire les chaines > - traduire, relire, relire, traduire > - prendre les captures d'écran et autres images de blocs > - passer la moulinette pour réinjecter la traduction (je fais) > - améliorer la moulinette pour la démocratiser (je fais en octobre) > - prévenir les auteurs pour atteindre les traducteurs dans d'autre > langues qu'on a ouvert une voie intéressante > > Bye, Mt. > >> On Tue, Sep 09, 2014 at 03:42:36PM +0200, Pierre Boudes wrote: >> >> >> Bonjour, >> >> C'est une bonne nouvelle que la mise en page éditable de creative >> programming soit disponible. >> >> * Synthèse rapide de ce message long >> >> ** Constat: >> - il y a beaucoup de travail de traduction, qu'il faut démarrer le plus tôt >> possible soit via un service web (que je ne veux pas assurer) soit via un >> dépôt git où il serait à mon avis préférable de manipuler du texte pas >> encore au format po pour rester convivial. >> - il y aura forcément un travail rébarbatif de remise en page manuelle et >> sans doute encore du travail pour s'en émanciper. >> >> ** Décisions à prendre >> Il y a quelques choix à faire, le reste en découlera : >> - faut-il s'organiser via un service web ou via git / github >> - si c'est git faut-il travailler directement sur des documents au format >> .po ou un autre format ? >> - taille des fragments / organisation page à page ou pas ? >> - faut-il dépenser de l'énergie à une mise en page automatisable ? >> >> Et maintenant la version longue pour celles et ceux qui ont le temps. >> >>> Le 8 sept. 2014 à 01:00, Martin Quinson <[email protected]> a écrit : >>> >>> Powerpoint a une approche trop différente de moi pour qu'on s'entende :) >> >> C'est ce que je me disais aussi, tu partais sur un truc ambitieux qui >> devrait marcher dans un monde idéal, mais l'écart culturel est trop >> important avec les auteurs et usagers de ce type de logiciels. Pour un >> document html, latex ou peut être Scribus ça pourrait marcher mais pas dans >> un univers sans culture du consensus ou de la convivialité en matière de >> code. >> >> Je pense qu'il faut décider d'une organisation de traduction maintenant pour >> aller au bout le plus rapidement possible pour une première version. Et si >> on envisage des évolutions du document original, il serait raisonnable >> d'accumuler de l'avance sur les traductions futures en capitalisant sur >> cette première traduction. >> >> Pour schématiser le processus : un traducteur ou une traductrice va prendre >> un fragment de texte du document original et le traduire en un fragment de >> texte qu'il faudra qu'un ou une graphiste remette en page pour former un >> document en français. Cette traduction pourra rester disponible pour la >> version suivante du document si le fragment de texte n'a pas changé. >> >> * Le travail de traduction >> Pour moins de 10 pages le travail d'une personne faisant à la fois office de >> graphiste et de traducteur suffirait, mais pour plus d'une centaine de pages >> de texte il nous faut un peu de coordination et surtout pouvoir ouvrir le >> travail de traduction à un maximum de personnes. >> >> L'accumulation coordonnée des actes de traduction permettra de traduire tout >> le texte, fragment par fragment sans doute dans un processus collaboratif. >> >> Comment ? Des outils spécifiques sont disponibles pour ce type de tâches. Il >> y a par exemple les outils orientés localisation d'application, autour du >> format .po. On peut également utiliser un logiciel de gestion de version, >> type git sur du texte plus ou moins formaté ou directement sur du .po. >> >> ** format po ? >> Le format .po est un bon format parce que l'id d'un fragment à traduire est >> le texte à traduire lui même. Par contre éditer le .po à la main suppose de >> veiller à faire des trucs pas naturels comme échapper certains caractères. >> Là où je l'ai vu utiliser, la mise en page en bout de chaîne était >> automatique (c'était du web). C'est aussi pour ce genre d'avantages qu'on >> s'ennuie avec le format .po. On devrait peut être s'en tenir à du texte plus >> convivial et éventuellement scripter la conversion vers du po le moment venu >> (ça devrait être facile). Nous devons ici nous mettre d'accord, passer un >> contrat ensemble sur la forme à utiliser. Cela dépendra peut être de la >> partie gestion collaborative. >> >> ** collaboration par service web ou git ? >> Je ne connais pas https://www.transifex.com proposé par Thierry Pasquier >> mais voici un exemple similaire de service web pour la traduction (ici du >> projet Diaspora) : >> https://webtranslateit.com/en/projects/3020-Diaspora/locales/en..fr/strings?status=to_proofread >> Ce que je sais, c'est que c'est efficace et confortable mais potentiellement >> privateur. Les traducteurs sont enregistrés pour une langue auprès du projet >> et peuvent proposer / relire / discuter / approuver des traductions de >> fragments de texte. Lorsqu'il y a de nouvelles tâches à effectuer (des >> fragments de texte de la langue de référence qui ont changé ou qui sont >> nouveaux ou bien des traductions proposées à relire / approuver), on reçoit >> un mail automatique. Il y a un espace de discussion associé à chaque paire >> fragment source, langue cible. Il arrive par exemple que les besoins de mise >> en page (ici un rendu dans le navigateur) poussent à raccourcir une >> traduction française après coup, ce qui donne lieu à un message dans la >> discussion. >> >> Ce type de service par son confort et sa modernité faciliterait certainement >> la constitution d'une équipe de traduction. Il est même possible que cette >> équipe puisse se rencontrer via le service de traduction (il doit bien y >> avoir des habitués des lieux). Je ne suis pas vraiment compétent la dedans >> et pour tout dire j'ai une légère aversion pour les services comme substitut >> de logiciel. Je ne sais pas qui paie le service pour Diaspora et comment >> reprendre la main facilement si le service cesse d'être intéressant. Par >> exemple, je ne sais pas si on peut récupérer facilement une sauvegarde des >> révisions. Git a cet avantage d'être auto-suffisant vis à vis de la >> surcouche github. Si github est vendu à Hachette demain on ne perdra >> quasiment rien. >> >> Si l'un ou l'une d'entre nous veut assurer l'hébergement de la traduction >> sur un service type transifex.com ou webtranslateit.com, en promettant de >> faire de son mieux pour maintenir le travail accessible et réutilisable, je >> suis partant. C'est même peut être la solution qui a ma préférence. Qui veut >> payer ce service et assurer le suivi pour quelques années ? >> >> L'alternative c'est git. Ça sera un peu plus difficile pour la gestion de la >> concurrence mais à peine : si deux personnes modifient chacune le même >> document, il faut fusionner leurs deux versions. On déporte aussi les >> espaces de discussion vers les messages de commit, c'est moins fun et moins >> local (au premier abord). Du côté des avantages on gagne par contre la >> possibilité de travailler correctement hors ligne (dans le train, etc.). Il >> y a l'inconvénient de devoir apprendre git pour participer à la traduction : >> on peut le contourner en demandant aux traducteurs occasionnels d'envoyer >> leurs modifs pour mail à une adresse montée pour l'occasion. >> >> ** accès à la mise en page >> Je pense que pour bien traduire il vaut mieux pouvoir trouver facilement où >> se trouve la chose que l'on traduit dans la mise en page d'origine >> (notamment pour comprendre le ton). C'est pourquoi il me semblait >> intéressant de conserver une organisation page à page (avec le numéro de >> page il est facile de s'y retrouver). Si on bosse sous git travailler avec >> un document par page permettrait aussi de limiter le travail de fusion de >> modifications concurrentes. >> >> ** taille des fragments >> Quoi qu'il en soit il faut prendre des fragments de texte qui ont une unité >> de sens, plutôt des paragraphes ou des phrases (et pourquoi pas les blocs de >> type texte dans la mise en page) surtout pas des lignes mises en page. >> >> * le travail de (re)mise en page >> >> Les avantages de séparer traduction et mise en page c'est : >> - éviter à chaque traducteur de s'improviser graphiste >> - éviter de devoir fusionner des documents aux formats complexes et fermés >> - permettre une remise en page "from scratch" (en html, latex, Scribus etc.) >> >> Sur un format powerpoint je ne crois pas que l'on puisse facilement remettre >> en page automatiquement le document. Ça n'empêche pas de creuser encore le >> sujet, mais le plus raisonnable est de faire un travail manuel de >> ré-injection du texte dans les pages. >> >> Dans le même temps on peut regarder comment obtenir un format de sortie >> alternatif html et/ou pdf généré à partir d'un format compatible avec >> l'approche po4a qui dans un monde idéal serait la bonne. >> >> J'ai déjà fait des mises en pages un peu plus élaborées que l'ordinaire en >> latex + pstricks puis tikz mais c'est assez compliqué et présente la plupart >> du temps peu d'intérêt par rapport à un véritable outil de mise en page. >> Cela dit c'est intéressant lorsque on a vraiment besoin d'un format proche >> du texte pur par exemple pour exploser le document en de nombreux fichiers >> ou pour faire de la gestion de révisions etc. Et il se trouve que Creative >> Programming s'y préterait bien : répétition des mêmes éléments graphiques et >> sémantiques tout au long du document, mise en page assez minimale, et notre >> besoin de typographier correctement des blocs de textes dont la taille va >> varier d'une langue à l'autre. >> >> Je peux travailler sur trois / quatre choses : >> - Si personne ne veut assurer la pérennité du service d'hébergement de >> traduction collaborative, je peux m'occuper ou aider à l'alternative git. Je >> peux par exemple m'occuper de maintenir le texte source et réinjecter des >> traductions reçues par mail. >> - Un peu de traduction (mais ça n'est sans doute pas mon fort), parce que >> c'est le gros du travail et que j'ai un intérêt personnel immédiat à voir ce >> document français sortir vite. Mais je ne suis pas la bonne personne pour >> coordonner la traduction proprement dite. >> - Proposer une autre mise en page compatible avec un traitement automatique >> des traductions, avant octobre. >> - Modifier les images / faire des captures d'écran francophones. >> >> >> A+ >> Pierre >> >> >> >> _______________________________________________ >> Discussion mailing list >> [email protected] >> http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion > > -- > Thou shalt study thy libraries and strive not to reinvent them without > cause, that thy code may be short and readable and thy days pleasant and > productive. -- Seventh commandment of the C programmer > <Page5.png> > _______________________________________________ > Discussion mailing list > [email protected] > http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion _______________________________________________ Discussion mailing list [email protected] http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
