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
