C'est super Martin. Et Transifex m'a l'air d'être un très bon choix. J'espère que tu trouveras le temps de faire tout ça !
>> TODO list: >> - ouvrir un projet transiflex qui permette de traduire les chaines >> - traduire, relire, relire, traduire J'ai très envie de m'y essayer aussi. >> - prendre les captures d'écran et autres images de blocs Je peux en faire. >> - passer la moulinette pour réinjecter la traduction (je fais) J'ai exploré quelques autres pistes à ce sujet. Une mise en page Scribus fournirait certainement le meilleur compromis entre format de fichier manipulable et facilité de travail pour des graphistes. Chaque paragraphe apparaît verbatim dans le format de fichier. On a un peu l'impression de travailler avec le Quark XPress d'il y a 20 ans, mais c'est assez efficace. A+ Pierre Le 10 sept. 2014 à 07:38, Claude Terosier <[email protected]> a écrit : > 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 _______________________________________________ Discussion mailing list [email protected] http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
