Nicolas,

Je suis admiratif devant tous les efforts fournis pour faire passer cette amélioration. Je le pense vraiment.

Malheureusement, comme tu as pu t'en rendre compte dans les différents échanges, le gain obtenu me (nous ?) semble quand même vraiment faible par rapport aux inconvénients potentiels (problème avec le terminal, saisie sur certains claviers, consignes aux traducteurs, non prise en charge dans certains outils, …).

Rien d'insurmontable, mais une balance globale qui peine à pencher d'un côté ou de l'autre, d'où je pense le manque de motivation.

Si Bruno le veut bien, on pourrait toutefois utiliser la fine dans un module GNOME à choisir, un peu comme projet pilote. Bruno, qu'en penses-tu ?

Claude

Le samedi 13 novembre 2010 à 19:21 +0100, Nicolas Delvaux a écrit :

Aller, je me permets une petite relance.

Reste-t-il des points à éclaircir ?

...

Salut à tous,

pour ceux qui ont oublié, je vous parlais il y a quelques temps de l'espace fine insécable (comme quoi elle devrait être utilisée à la place des espaces insécables devant :!;?» et derrière « ). Vu qu'on manquait de recul et de tests, j'ai rédigé un compte rendu sur le sujet cet été : http://malaria.perso.sfr.fr/fines/fines.pdf

Concernant ce qui nous intéresse ici, il ne semble y avoir aucun problème de support de la fine avec les applications GTK et la plateforme Gnome. Je pense que mes tests sont assez exhaustifs, dans le cas contraire j'attends vos suggestions.

Bref, sachant que les règles typographiques de Gnome ( http://traduc.org/gnomefr/Typographie ) mentionnent l'espace fine insécable mais déconseillent son usage « du fait de [s]a faible prise en charge » et que nous savons maintenant qu'il n'y a pas/plus de problème technique, pourquoi ne pas profiter de ce nouveau cycle (qui plus est de la 3.0) pour adopter l'espace fine insécable ?

La transition n'est pas compliquée, dans la plupart des cas, les traducteurs doivent juste substituer l'espace insécable (Ctrl + Maj

• espace) par l'espace fine insécable (Alt Gr + v).

Convertir un .po se fait également très simplement, il suffit de faire un « chercher/remplacer tout » sur les espaces insécables (la chose est facilement automatisable/scriptable si nécessaire).

Je veux dire par là que la décision me semble reposer uniquement sur une question de volonté, rien d'autre ne semble s'y opposer (AMHA).

Bref, qu'en pensez vous ? Y a-t-il encore quelques zones d'ombre qui mériteraient d'être éclaircies avant de se lancer ?

Cordialement, Nicolas _______________________________________________ Gnomefr mailing list Gnomefr@traduc.org http://listes.traduc.org/mailman/listinfo/gnomefr

---

Gnomefr mailing list Gnomefr@traduc.org http://listes.traduc.org/mailman/listinfo/gnomefr

Bonsoir,

Voici une réponse groupée pour Bruno et Claude :

Malheureusement, comme tu as pu t'en rendre compte dans les différents échanges, le gain obtenu me (nous ?) semble quand même vraiment faible par rapport aux inconvénients potentiels

Par cette discussion je cherche aussi à savoir s'il reste des problèmes techniques importants à résoudre en vu de cette adoption. En ce qui concerne les différents problèmes que tu cites :

problème avec le terminal

- Il n'y a pas de problème avec les terminaux usuels, mais il y en a effectivement un avec les TTY. Ce problème a été corrigé en amont (KBD), mais compte tenu de la lenteur du cycle de sorti du projet en question (tous les 7-8 mois), il est possible que le problème ne soit effectivement corrigé sur la plupart des distributions que d'ici la fin de l'année prochaine (en étant un poil pessimiste). Après reste à voir si les applications Gnome sont souvent utilisées dans un TTY... Je ne pense pas que ce problème soit bloquant, mais c'est à vous de voir.

saisie sur certains claviers

- La saisie est en effet un problème, par exemple sur les claviers Canadien (quoi que ça demande confirmation et puis je ne sais pas quel est l'agencement Canadien/Québécois par défaut/le plus utilisé). Techniquement ça ne doit pas être bien compliqué d'assigner une combinaison de touches à un caractère, si la chose est confirmée et que quelqu'un sait à qui s'adresser, la chose peut potentiellement être réglée rapidement. Il est également difficile de taper une espace fine insécable depuis Windows. Mais vu qu'il en est de même pour les majuscules accentuées et les guillemets français, on ne peut pas considérer ça comme étant bloquant (AMHA).

consignes aux traducteurs

- C'est pourtant simple, non ? Un petit temps d'adaptation peut-être, mais vu qu'il s'agit, grosso-modo, de substituer un raccourci clavier par un autre...

non prise en charge dans certains outils

Comme quoi par exemple ? C'est le genre de chose qu'il faut dire haut et fort si on veut que ce soit réglé un jour. ;-)

D'autre part, je ne crois pas que tu (Nicolas) te rend vraiment compte du temps de travail que cela représente (je sais, on te la déjà dit) . -- Ce n'est pas un simple remplacement comme tu le dis :

1. l'espace insécable n'est pas utilisé que devant les : et ; mais il

me semble également entre M. et Dupond, avant les unités de mesures "15 cm" etc. Doit-on remplacer également ceux-là ? 2) donc il s'agit plutôt de six remplacements et encore en supposant que l'espace insécable ne soit jamais séparé du l'élément qui le suit par exemple : "voici les trois élément à considérer " ": le rouge, le bleu..." car le remplacement automatique ne marche plus.

Si on parle ici de remplacement automatique, c'est bien que la chaine de caractère en question a déjà été traduite. Pour reprendre ton exemple, la chaine ": le rouge, le bleu..." serait en fait déjà " : le rouge, le bleu..." (avec une espace insécable devant « : ») dans le fichier .po, donc en partant de là le remplacement automatique fonctionnerait parfaitement. ;-)

Au passage, il semble bien que l'espace entre un nombre et une unité (comme "cm", "€") puisse également être une espace fine insécable (à priori les deux sont tolérés, je n'ai pas trouvé de règle claire et précise sur le sujet).

Cependant il est vrai que ma proposition initiale de faire un bête chercher/remplacer-tous sur le caractère de l'espace insécable était un peu « violente ». Il serait en effet plus subtile et sage de chercher/remplacer les chaines suivantes : " :", " ;", "« ", " »", " !", " ?". C'est certes un peu plus compliqué, mais la chose est aisément scriptable si besoin.

Une telle méthode ne corrigerait certes pas les éventuelles erreurs de traductions, mais je ne vois pas comment elle en créerait de nouvelles (tout contre exemple est le bienvenu).

Ceux qui voudront tout de même tout vérifier visuellement peuvent le faire : sachant que les chaines concernées ne sont qu'une petite partie de l'ensemble, ça doit tout de même pouvoir être fait dans un temps raisonnable.

Quel logiciel d'édition marque clairement visuellement la différence ?

Comment vous faites actuellement pour différencier une espace classique d'une espace insécable ?

Il est vrai que beaucoup (la plupart) des éditeurs utilisent par défaut une police à chasse fixe, ce qui implique qu'aucune différence visible n'est affichée entre une espace fine et une espace classique. Cependant, il existe une astuce simple : utiliser un éditeur de texte qui surligne les résultats de recherche dans tous le texte. La plupart (tous sauf le bloc note Windows ?) le font, ce qui implique qu'une recherche sur le caractère " " surligne (et donc discrimine) toutes les espaces fines insécables du fichier en question.

-- Ensuite il faut donc commiter les modifs. Pour moi, un commit prend disons AU MOINS 15 minutes multiplié par le nombre de fichier po, cela fait déjà pas mal d'heures de travail.

Je ne parle bien évidemment pas de faire des commits UNIQUEMENT pour passer à l'espace fine insécable !

Partant du principe qu'une nouvelle version de Gnome sort tous les 6 mois, je me dis qu'une bonne partie des .po sont édités et commités dans ce laps de temps. Il s'agirait en fait ici de profiter de l'édition d'un .po (pour traduire de nouvelles chaines par exemple) pour en même temps passer à la fine. Tout de suite on perd beaucoup moins de temps. :-)

Je ne sais pas comment se passe le commit techniquement (file d'attente ? Le coordinateur a un accès git sur tous les projets ? Envois du .po par mail au mainteneur ?), mais il y a peut-être moyen d'automatiser en passant tous les .po par un script de conversion avant chaque commit.

Il me semble qu'ils utilisent des scripts de ce genre chez Traduc pour vérifier certains aspects des traductions... À voir.

Pour ce qui est de la proposition, je pense également que ce travail ne peut se faire que petit à petit au bon vouloir des gens, donc pourquoi pas un module précis... si vraiment vous y tenez pour tester qu'il n'y a pas de problèmes avec GTK.

Cette décision vous appartiens. Cependant, si vous décidez de ne partir que sur un seul module pour commencer, je vous conseillerais un gros module du genre Evolution, histoire d'être sûr d'avoir des retours en cas de problème (ça ne sert à rien si le module est trop peu utilisé).

Sinon, on peut aussi laisser le travail de conversion à Nicolas, en nous chargeant seulement du commit....

Donc voilà, ce n'est pas vraiment nécessaire n'est-ce pas ?

Sachant qu'il ne s'agit que de l'étape de conversion ; une fois passée (de façon totalement transparente s'il s'agit d'un script), tout redevient comme avant (en ayant changé un raccourcis clavier par un autre).

Sur ce, bonne nuit à tous. ;-)

Nicolas

    Nicolas,

    Je suis admiratif devant tous les efforts fournis pour faire
    passer
    cette amélioration. Je le pense vraiment.

    Malheureusement, comme tu as pu t'en rendre compte dans les
    différents
    échanges, le gain obtenu me (nous ?) semble quand même
    vraiment faible
    par rapport aux inconvénients potentiels (problème avec le
    terminal,
    saisie sur certains claviers, consignes aux traducteurs, non
    prise en
    charge dans certains outils, …).

    Rien d'insurmontable, mais une balance globale qui peine à
    pencher d'un
    côté ou de l'autre, d'où je pense le manque de motivation.

    Si Bruno le veut bien, on pourrait toutefois utiliser la fine
    dans un
    module GNOME à choisir, un peu comme projet pilote. Bruno,
    qu'en
    penses-tu ?

    Claude

    Le samedi 13 novembre 2010 à 19:21 +0100, Nicolas Delvaux a
    écrit :


    > Aller, je me permets une petite relance.
    >
    >
    > Reste-t-il des points à éclaircir ?
    >
    >
    >
    > > Salut à tous,
    > >
    > > pour ceux qui ont oublié, je vous parlais il y a quelques
    temps de
    > > l'espace fine insécable (comme quoi elle devrait être
    utilisée à la
    > > place des espaces insécables devant :!;?» et derrière « ).
    > > Vu qu'on manquait de recul et de tests, j'ai rédigé un
    compte rendu
    > > sur le sujet cet été :
    http://malaria.perso.sfr.fr/fines/fines.pdf
    > >
    > > Concernant ce qui nous intéresse ici, il ne semble y avoir
    aucun
    > > problème de support de la fine avec les applications GTK
    et la
    > > plateforme Gnome.
    > > Je pense que mes tests sont assez exhaustifs, dans le cas
    contraire
    > > j'attends vos suggestions.
    > >
    > > Bref, sachant que les règles typographiques de Gnome
    > > ( http://traduc.org/gnomefr/Typographie ) mentionnent
    l'espace fine
    > > insécable mais déconseillent son usage  « du fait de [s]a
    faible
    > > prise en charge » et que nous savons maintenant qu'il n'y
    a pas/plus
    > > de problème technique, pourquoi ne pas profiter de ce
    nouveau cycle
    > > (qui plus est de la 3.0) pour adopter l'espace fine
    insécable ?
    > >
    > > La transition n'est pas compliquée, dans la plupart des
    cas, les
    > > traducteurs doivent juste substituer l'espace insécable
    (Ctrl + Maj
    > > + espace) par l'espace fine insécable (Alt Gr + v).
    > > Convertir un .po se fait également très simplement, il
    suffit de
    > > faire un « chercher/remplacer tout » sur les espaces
    insécables (la
    > > chose est facilement automatisable/scriptable si
    nécessaire).
    > >
    > > Je veux dire par là que la décision me semble reposer
    uniquement sur
    > > une question de volonté, rien d'autre ne semble s'y
    opposer (AMHA).
    > >
    > > Bref, qu'en pensez vous ?
    > > Y a-t-il encore quelques zones d'ombre qui mériteraient
    d'être
    > > éclaircies avant de se lancer ?
    > >
    > >
    > > Cordialement,
    > > Nicolas

Bonsoir,

Quel est l'intérêt pour le projet ?

Comme déjà dit, c'est avant tout une question d'ordre esthétique. Accessoirement, il s'agit de respecter les règles typographiques françaises.

Nous sommes des volontaires ce que vous proposez n'est même pas d'actualité pour les professionnels de la traduction.

L'espace fine insécable est utilisée depuis (presque) la nuit des temps dans la presse écrite. Au passage, elle est donc aussi supportée dans les logiciels métiers que ces gens là utilisent (quelqu'un ayant travaillé dans la presse écrite me l'a confirmé).

Il est cependant vrai que *dans l'informatique non spécialisée*, pour cause d'un support technique défaillant voir inexistant de la fine à l'époque, il a été décidé d'utiliser l'espace insécable classique car on avait simplement pas le choix.

Je pars simplement du principe que maintenant qu'il n'y a plus de problèmes techniques, on devrait revenir dans le « droit chemin » (et donc au préalable corriger les éventuels petits problèmes restants). En l'occurrence, hormis le problème de la transition en elle même, il ne semble plus y avoir de problème technique (concernant Gnome).

Après oui, je veux bien te croire quand tu dis que les professionnels de la traduction *dans le domaine informatique* ne s'intéressent pas à la fine pour le moment. Mais est-ce que cela devrait avoir une quelconque influence sur Gnome ? Non, évidemment. C'est le principe de l'indépendance (et même du logiciel libre si tu veux mon avis).

Il faut savoir que tout les logiciels et leurs fichiers d'aide vont évoluer d'ici à la version 3.0. Le volume est très important et devoir reprendre la traduction, rendre obsolète les mémoires de traductions me semble inutile.

Nous allons devoir en plus mettre à jour de façon assez radicale le système d'aide avec le passage à Mallard. Mon expérience de cette mise à jour (f-spot) est que nous allons avoir beaucoup de travail.

Je n'ai JAMAIS envisagé la « transition » comme devant être faite à la main, je crois que je n'aurais même pas proposé l'idée si ça c'était le cas.

Il se trouve que j'ai un script de conversion en local qui semble plutôt bien fonctionner (en tous cas il passe tous les pièges dont Bruno avait parlé dimanche dernier). Je compte le tester de façon plus approfondie avant de le soumettre sur la liste (Bruno a dit qu'il ne tolérerait aucun bug ! ;-)).

Au passage (@Bruno, et autres commiteurs ?), il s'agit pour le moment d'un script de conversion uniquement ; on m'a dit qu'il y avait déjà des scripts de vérification/correction des erreurs de traductions usuelles. Vu que j'ai cru comprendre que mon script devais être un « tout en un », j'aimerais avoir accès à ceux-ci pour pouvoir leur offrir un successeur (au moins) aussi performant. ;-) (dites le si ça pose problème, mais c'est frustrant pour un programmeur de devoir attendre pour finir son programme ! :-p)

Bref, tous ça pour dire que si j'arrive à mes fins avec ce script, la transition sera potentiellement transparente pour tout le monde, c'est à dire sans aucune autre « charge de travail » que de devoir changer ses habitudes en utilisant un raccourcis clavier au lieu d'un autre (sauf quelques rares exceptions).

Dans le pire des cas, on ne se retrouvera jamais dans une situation ou il faudra éditer manuellement toutes les chaines. Rassuré ?

Pour finir J'ai pu faire un petit test de configuration du clavier. J'ai du changer mon espace insécable de base Maj.+Espace en Espace insécable 3e niveau et fine insécable au 4e niveau

J'ai aussi du changer le 3e niveau avant d'avoir quelque chose de fonctionnel dans gtranslator. gtranslator affiche l'espace insécable comme un petit triangle inversé et l'espace fine insécable comme un petit rectangle vide. (gtranslator ne gère pas le Ctrl+Espace pour l'espace insécable qui est un raccourci pour copier la source dans la traduction).

Je t'avoues ne pas avoir bien compris ce passage... Le raccourcis clavier « Alt Gr + v » ne marchait pas chez toi ? Et chez moi (réglage par défaut) c'est « Alt Gr + Maj + Espace » pour avoir une espace insécable classique. Bon, de toute manière, tu as bien le droit de configurer ton clavier comme tu le souhaites. ;-)

Désolé d'être aussi brusque nous sommes tous plus ou moins idéalistes sinon nous ne participerions pas à ce chantier du libre. Je comprend le but que tu poursuis mais je ne pense pas que ce changement soit utile. Je pense aussi qu'il est trop lourd au vu de ce qui nous attend avec Gnome 3.0.

Voilà j'espère t'avoir au moins un peu rassuré sur mes intentions.

Cordialement, Nicolas

Salut à tous,

Suite à une discussion avec Bruno, j'ai le plaisir de vous présenter une version nettement améliorée de mon script de vérification/correction.

Voici les changements par rapport à hier :

- Beaucoup moins de « faux positifs » dans la liste des erreurs « potentielles » (ça reste très variable selon les .po) ; - Chaque erreur vient avec son contexte (plus besoin de naviguer entre le .po et la liste des erreurs pour vérifier si une erreur est fondée ou pas) ; - Le script détecte (et signal) maintenant la présence de plusieurs espaces à la suite ; - La détection de la validité des balises XML a été complétée et grandement améliorée ; - L'indicateur d'avancement est maintenant plus compréhensible ; - Le diff entre le .po original et le .po corrigé n'est plus généré automatiquement (c'était assez inutile et c'est facilement faisable manuellement si besoin).

De plus, vous pouvez maintenant rajouter « --ortho » en argument sur la ligne de commande pour qu'un fichier ne contenant que les chaines traduites soit créé. Ça permet de gagner du temps si vous souhaitez chasser les fautes d'orthographe avec un éditeur de texte. (au début il faudra tout de même lui dire d'ignorer certains mots, mais il ne faut le faire qu'une seule fois à priori).

Voilà, ça me parait déjà pas mal. Je précise aussi que ce script est sous licence BSD, chacun peut l'adapter et le redistribuer comme bon lui semble. Cependant, vu que ce script pourrai également servir à d'autres équipes de traducteurs, il serait tout de même souhaitable de centraliser les améliorations/corrections. (si besoin, il devrait-être possible de l'héberger sur traduc)

Le script peut toujours être téléchargé à la même adresse : http://malaria.perso.sfr.fr/francisator.tar.gz

Bonne soirée ! Nicolas

Le samedi 20 novembre 2010 à 17:58 +0100, Nicolas Delvaux a écrit :

Salut à tous,

Chose promise, chose due voici le fameux script dont nous parlions la semaine dernière : http://malaria.perso.sfr.fr/francisator.tar.gz Je vais essayer de vous dire tout ce qu'il faut savoir de manière concise (c'est pas gagné :-p).

Dans l'archive sur lequel pointe le lien ci-dessus, vous trouverez deux choses :

• le script en lui même (francisator.sh)
• un fichier de test (test.po)

Vu qu'il peut-être très pénible de vérifier tout ce que fait le script sur des fichier .po de plusieurs milliers de lignes, il est beaucoup plus commode d'utiliser un fichier de test pour mettre le script à l'épreuve. Libre à vous de modifier/compléter ce fichier test en y mettant les situations les plus improbables que le script pourrait jamais rencontrer (enfin il faut tout de même que ça reste un fichier .po valide ;-)).

Que fait le script ?

1/ Il corrige directement les espaces devant les signes de ponctuation qui vont bien (il remplace les espace et les espaces insécables par des espaces fines insécables) → vu qu'il s'agit d'une correction automatique, c'est bien sûr cette partie qui doit être particulièrement testée. D'après mes tests elle est 100% fiable. Tous les pièges cités par Bruno la semaine dernière sont déjoués (et ce ne sont pas les seuls). L'intérêt est de pouvoir faire confiance à cette partie du script : s'il faut examiner attentivement des diff de corrections de plusieurs centaines de lignes à chaque fois, ça n'a aucun intérêt. Utilisez le fichier test pour vous convaincre de sa fiabilité et/ou trouver des bugs qui m'auraient échappé !

2/ Le script vérifie également la présence de certaines erreurs *potentielles*. Notez bien que vu que ces erreurs sont potentielles, elles ne sont que *signalées* (et non corrigées directement). Pour chaque problème, le script vous indique la ligne correspondante (ce qui est très pratique). Voici la liste des choses qui sont vérifiées :

• Présence d'autant de balise ouvrantes que fermantes (détecte par

exemple "<gui><em>Test !<em></gui>")

• Un signe de ponctuation non précédé par une espace fine insécable

(car la substitution automatique ne touche pas à certains cas tendancieux)

• Présence d'une espace insécable (il est sensé en rester très peu

voir aucune après la correction automatique, c'est donc louche)

• Emploi d'un « B » dans une unité au lieu d'un « o » pour un octet

(d'après mon expérience, c'est une erreur assez fréquente chez les débutants)

3/ Le script applique les 2 points précédents uniquement sur les chaines traduites (blocs « msgstr »). Les commentaires et les chaines originales ne sont pas modifiés.

Voilà. J'ai testé le tout avec succès avec plusieurs .po officiels. Par exemple avec Rhythmbox (plus de 1200 chaines), je confirme n'avoir trouvé aucune erreur dans la correction automatique. De plus le script détecte 17 erreurs potentielles, mais il semble que seule une soit vraiment fondée (une espace insécable curieusement placée ligne 2426).

J'attends vos remarques et commentaires. Je suis également à l'écoute si vous avez des idées pour améliorer le script (d'autres types d'erreurs à vérifier par exemple).

Bon week-end, Nicolas

ps : (rappel) en attendant que ce bug soit officiellement résolu ( https://bugzilla.gnome.org/show_bug.cgi?id=626126 ), la manière la plus simple de reconnaitre une espace fine insécable d'une espace insécable dans gedit (par exemple) est de lancer une recherche sur le caractère souhaité. Celui-ci sera alors surligné dans tout le fichier.

Félicitation pour ton travail.

Parlons "politique" maintenant puisque tu y tiens. Il te reste à me convaincre au sujet de tes histoires d'espace fine insécable avant une quelconque généralisation de la procédure maintenant que cela me semble faisable grâce à ton script : 1) je m'étonne car dans tous les documents que j'ai trouvé, il est dit que devant le symbole (:), il faut mettre un espace insécable normal ??? 2) je n'ai trouvé aucun document officiel qui nous fixe les règles en usage en français ???

Pourrais-tu me fournir des références officielles concernant les règles en usage en France ?

Ensuite, pour répondre à ta question, je crois que nous avons déjà décidé que nous étions prêt à faire un essai sur un gros module de traduction pour voir si cela posait des problèmes informatique, nous n'avons juste pas encore choisi le module pour GNOME 3.0. Patience, on a encore quelques mois.

Cordialement

Bruno

Le 26 novembre 2010 20:16, Nicolas Delvaux nicolas.delvaux@gmx.com a écrit :

Salut à tous,

voici encore une nouvelle version de mon script de correction/vérification des .po.

Liste des nouveautés :

• Le script est presque deux fois plus rapide ;
• Le script détecte (et signal) maintenant si une chaine et sa traduction

ne se terminent pas par le même signe de ponctuation ;

• L'option « --ortho » à été améliorée

Voilà pour cette fois. Pour le téléchargement, c'est toujours ici : http://malaria.perso.sfr.fr/francisator.tar.gz

Je pense que le script commence à être mature, n'hésitez pas à vérifier vos .po avec son aide.

Reste maintenant LA grande question : qu'en est-il des espaces fines insécables ? Vu que le script fait tout le boulot (et plus encore), je pense que la décision n'est plus que politique maintenant.

Bonne soirée, Nicolas

Le dimanche 21 novembre 2010 à 21:40 +0100, Nicolas Delvaux a écrit :

Salut à tous,

Suite à une discussion avec Bruno, j'ai le plaisir de vous présenter une version nettement améliorée de mon script de vérification/correction.

Voici les changements par rapport à hier :

• Beaucoup moins de « faux positifs » dans la liste des erreurs «

potentielles » (ça reste très variable selon les .po) ;

• Chaque erreur vient avec son contexte (plus besoin de naviguer entre le

.po et la liste des erreurs pour vérifier si une erreur est fondée ou pas) ;

• Le script détecte (et signal) maintenant la présence de plusieurs espaces

à la suite ;

• La détection de la validité des balises XML a été complétée et grandement

améliorée ;

• L'indicateur d'avancement est maintenant plus compréhensible ;
• Le diff entre le .po original et le .po corrigé n'est plus généré

automatiquement (c'était assez inutile et c'est facilement faisable manuellement si besoin).

De plus, vous pouvez maintenant rajouter « --ortho » en argument sur la ligne de commande pour qu'un fichier ne contenant que les chaines traduites soit créé. Ça permet de gagner du temps si vous souhaitez chasser les fautes d'orthographe avec un éditeur de texte. (au début il faudra tout de même lui dire d'ignorer certains mots, mais il ne faut le faire qu'une seule fois à priori).

Voilà, ça me parait déjà pas mal. Je précise aussi que ce script est sous licence BSD, chacun peut l'adapter et le redistribuer comme bon lui semble. Cependant, vu que ce script pourrai également servir à d'autres équipes de traducteurs, il serait tout de même souhaitable de centraliser les améliorations/corrections. (si besoin, il devrait-être possible de l'héberger sur traduc)

Le script peut toujours être téléchargé à la même adresse : http://malaria.perso.sfr.fr/francisator.tar.gz

Bonne soirée ! Nicolas

Le samedi 20 novembre 2010 à 17:58 +0100, Nicolas Delvaux a écrit :

Salut à tous,

Chose promise, chose due voici le fameux script dont nous parlions la semaine dernière : http://malaria.perso.sfr.fr/francisator.tar.gz Je vais essayer de vous dire tout ce qu'il faut savoir de manière concise (c'est pas gagné :-p).

Dans l'archive sur lequel pointe le lien ci-dessus, vous trouverez deux choses :

• le script en lui même (francisator.sh)
• un fichier de test (test.po)

Vu qu'il peut-être très pénible de vérifier tout ce que fait le script sur des fichier .po de plusieurs milliers de lignes, il est beaucoup plus commode d'utiliser un fichier de test pour mettre le script à l'épreuve. Libre à vous de modifier/compléter ce fichier test en y mettant les situations les plus improbables que le script pourrait jamais rencontrer (enfin il faut tout de même que ça reste un fichier .po valide ;-)).

Que fait le script ?

1/ Il corrige directement les espaces devant les signes de ponctuation qui vont bien (il remplace les espace et les espaces insécables par des espaces fines insécables) → vu qu'il s'agit d'une correction automatique, c'est bien sûr cette partie qui doit être particulièrement testée. D'après mes tests elle est 100% fiable. Tous les pièges cités par Bruno la semaine dernière sont déjoués (et ce ne sont pas les seuls). L'intérêt est de pouvoir faire confiance à cette partie du script : s'il faut examiner attentivement des diff de corrections de plusieurs centaines de lignes à chaque fois, ça n'a aucun intérêt. Utilisez le fichier test pour vous convaincre de sa fiabilité et/ou trouver des bugs qui m'auraient échappé !

2/ Le script vérifie également la présence de certaines erreurs *potentielles*. Notez bien que vu que ces erreurs sont potentielles, elles ne sont que *signalées* (et non corrigées directement). Pour chaque problème, le script vous indique la ligne correspondante (ce qui est très pratique). Voici la liste des choses qui sont vérifiées :

• Présence d'autant de balise ouvrantes que fermantes (détecte par exemple

"<gui><em>Test !<em></gui>")

• Un signe de ponctuation non précédé par une espace fine insécable (car la

substitution automatique ne touche pas à certains cas tendancieux)

• Présence d'une espace insécable (il est sensé en rester très peu voir

aucune après la correction automatique, c'est donc louche)

• Emploi d'un « B » dans une unité au lieu d'un « o » pour un octet

(d'après mon expérience, c'est une erreur assez fréquente chez les débutants)

3/ Le script applique les 2 points précédents uniquement sur les chaines traduites (blocs « msgstr »). Les commentaires et les chaines originales ne sont pas modifiés.

Voilà. J'ai testé le tout avec succès avec plusieurs .po officiels. Par exemple avec Rhythmbox (plus de 1200 chaines), je confirme n'avoir trouvé aucune erreur dans la correction automatique. De plus le script détecte 17 erreurs potentielles, mais il semble que seule une soit vraiment fondée (une espace insécable curieusement placée ligne 2426).

J'attends vos remarques et commentaires. Je suis également à l'écoute si vous avez des idées pour améliorer le script (d'autres types d'erreurs à vérifier par exemple).

Bon week-end, Nicolas

ps : (rappel) en attendant que ce bug soit officiellement résolu ( https://bugzilla.gnome.org/show_bug.cgi?id=626126 ), la manière la plus simple de reconnaitre une espace fine insécable d'une espace insécable dans gedit (par exemple) est de lancer une recherche sur le caractère souhaité. Celui-ci sera alors surligné dans tout le fichier.

---

Gnomefr mailing list Gnomefr@traduc.org http://listes.traduc.org/mailman/listinfo/gnomefr

Le 27 novembre 2010 12:20, Nicolas Delvaux nicolas.delvaux@gmx.com a écrit :

Le vendredi 26 novembre 2010 à 23:24 +0100, annoa.b@gmail.com a écrit :

Félicitation pour ton travail.

Parlons "politique" maintenant puisque tu y tiens. Il te reste à me convaincre au sujet de tes histoires d'espace fine insécable avant une quelconque généralisation de la procédure maintenant que cela me semble faisable grâce à ton script :

1. je m'étonne car dans tous les documents que j'ai trouvé, il est dit que

devant le symbole (:), il faut mettre un espace insécable normal ??? 2) je n'ai trouvé aucun document officiel qui nous fixe les règles en usage en français ???

Pourrais-tu me fournir des références officielles concernant les règles en usage en France ?

La règle est de mettre une espace fine insécable devant les signes de ponctuations doubles, c'est à dire devant les signes qui ont la hauteur d'un caractère (et donc devant les caractères :;!?» et «)

Tu ne m'as pas du tout convaincu. Les références ci-dessous ne sont même pas d'accord avec TA règle. Je parlais plutôt de source officielle (surtout pas wikipedia ou une université parmi une autre). Je peux te donner autant de page Web que tu m'en fourniras qui diront le contraire.

Enfin c'est pas grave, je pense qu'il n'y a pas de règle (seul l'insécabilité est obligatoire) donc c'est une question d'esthétisme (qui ne se voit pas sur un ordinateur) donc pourquoi pas essayer avec un module. De toute façon personne ne viendra se plaindre si son espace est fine puisque cela ne se voit pas.

J'ai essayé de comprendre là où il n'y a rien à comprendre, désolé

Bon courage pour essayer de convaincre toutes les autres équipes... y compris Microsoft et MAC pour parler de la non minorité. J'espère seulement que cette histoire d'espace fine n'aura aucune incidence avec une quelconque compatibilité entre Windows et le reste.

Bruno

PS. : je vois avec Claude pour décider du (ou des modules) qu'on met à l'essai. On t'en informera lorsqu'on aura choisi.

Quelques sources :

Les règles typographiques de l'université Paris Diderot :

http://www.eila.univ-paris-diderot.fr/sysadmin/gestion-docs/typo-francaise#p...

L'éditeur du fameux logiciel d'aide à la rédaction « Antidote » : http://www.druide.com/points_de_langue_13.html

Enfin, la page « ponctuation » sur Wikipedia : http://fr.wikipedia.org/wiki/Ponctuation (si ça peut vous rassurer, je jure solennellement de ne pas avoir modifié cette page)

Cependant, il est vrai que l'on trouve aussi des sources contradictoires concernant le symbole « : ». Je ne sais pas d'où vient ce « conflit ». Différents courants de pensée chez les typographes ?

De ce point de vu là, je suis pour adopter une attitude pragmatique :

• On rencontre les deux règles, donc on peut éventuellement admettre

qu'aucune des deux ne peut être considérée comme étant foncièrement fausse (même si personnellement je suis pour l'espace fine devant les deux points, entre autre parce que je trouve ça plus esthétique).

• Vu que les deux ponctuations sont possibles et que l'on doit utiliser

l'espace fine insécable devant les autres signes de ponctuation double, il serait, je pense, plus pratique de l'utiliser également devant les deux points : cela nous évitera de jongler en permanence entre la fine et l'insécable classique, l'usage de cette dernière devenant alors très marginal.

Ensuite, pour répondre à ta question, je crois que nous avons déjà décidé que nous étions prêt à faire un essai sur un gros module de traduction pour voir si cela posait des problèmes informatique, nous n'avons juste pas encore choisi le module pour GNOME 3.0. Patience, on a encore quelques mois.

D'accord, sur le principe ça ne me pose aucun problème.

Cordialement, Nicolas

Le 26 novembre 2010 20:16, Nicolas Delvaux nicolas.delvaux@gmx.com a écrit :

Salut à tous,

voici encore une nouvelle version de mon script de correction/vérification des .po.

Liste des nouveautés :

• Le script est presque deux fois plus rapide ;
• Le script détecte (et signal) maintenant si une chaine et sa traduction

ne se terminent pas par le même signe de ponctuation ;

• L'option « --ortho » à été améliorée

Voilà pour cette fois. Pour le téléchargement, c'est toujours ici : http://malaria.perso.sfr.fr/francisator.tar.gz

Je pense que le script commence à être mature, n'hésitez pas à vérifier vos .po avec son aide.

Reste maintenant LA grande question : qu'en est-il des espaces fines insécables ? Vu que le script fait tout le boulot (et plus encore), je pense que la décision n'est plus que politique maintenant.

Bonne soirée, Nicolas

Le dimanche 21 novembre 2010 à 21:40 +0100, Nicolas Delvaux a écrit :

Salut à tous,

Suite à une discussion avec Bruno, j'ai le plaisir de vous présenter une version nettement améliorée de mon script de vérification/correction.

Voici les changements par rapport à hier :

• Beaucoup moins de « faux positifs » dans la liste des erreurs «

potentielles » (ça reste très variable selon les .po) ;

• Chaque erreur vient avec son contexte (plus besoin de naviguer entre le

.po et la liste des erreurs pour vérifier si une erreur est fondée ou pas) ;

• Le script détecte (et signal) maintenant la présence de plusieurs espaces

à la suite ;

• La détection de la validité des balises XML a été complétée et grandement

améliorée ;

• L'indicateur d'avancement est maintenant plus compréhensible ;
• Le diff entre le .po original et le .po corrigé n'est plus généré

automatiquement (c'était assez inutile et c'est facilement faisable manuellement si besoin).

De plus, vous pouvez maintenant rajouter « --ortho » en argument sur la ligne de commande pour qu'un fichier ne contenant que les chaines traduites soit créé. Ça permet de gagner du temps si vous souhaitez chasser les fautes d'orthographe avec un éditeur de texte. (au début il faudra tout de même lui dire d'ignorer certains mots, mais il ne faut le faire qu'une seule fois à priori).

Voilà, ça me parait déjà pas mal. Je précise aussi que ce script est sous licence BSD, chacun peut l'adapter et le redistribuer comme bon lui semble. Cependant, vu que ce script pourrai également servir à d'autres équipes de traducteurs, il serait tout de même souhaitable de centraliser les améliorations/corrections. (si besoin, il devrait-être possible de l'héberger sur traduc)

Le script peut toujours être téléchargé à la même adresse : http://malaria.perso.sfr.fr/francisator.tar.gz

Bonne soirée ! Nicolas

Le samedi 20 novembre 2010 à 17:58 +0100, Nicolas Delvaux a écrit :

Salut à tous,

Chose promise, chose due voici le fameux script dont nous parlions la semaine dernière : http://malaria.perso.sfr.fr/francisator.tar.gz Je vais essayer de vous dire tout ce qu'il faut savoir de manière concise (c'est pas gagné :-p).

Dans l'archive sur lequel pointe le lien ci-dessus, vous trouverez deux choses :

• le script en lui même (francisator.sh)
• un fichier de test (test.po)

Vu qu'il peut-être très pénible de vérifier tout ce que fait le script sur des fichier .po de plusieurs milliers de lignes, il est beaucoup plus commode d'utiliser un fichier de test pour mettre le script à l'épreuve. Libre à vous de modifier/compléter ce fichier test en y mettant les situations les plus improbables que le script pourrait jamais rencontrer (enfin il faut tout de même que ça reste un fichier .po valide ;-)).

Que fait le script ?

1/ Il corrige directement les espaces devant les signes de ponctuation qui vont bien (il remplace les espace et les espaces insécables par des espaces fines insécables) → vu qu'il s'agit d'une correction automatique, c'est bien sûr cette partie qui doit être particulièrement testée. D'après mes tests elle est 100% fiable. Tous les pièges cités par Bruno la semaine dernière sont déjoués (et ce ne sont pas les seuls). L'intérêt est de pouvoir faire confiance à cette partie du script : s'il faut examiner attentivement des diff de corrections de plusieurs centaines de lignes à chaque fois, ça n'a aucun intérêt. Utilisez le fichier test pour vous convaincre de sa fiabilité et/ou trouver des bugs qui m'auraient échappé !

2/ Le script vérifie également la présence de certaines erreurs *potentielles*. Notez bien que vu que ces erreurs sont potentielles, elles ne sont que *signalées* (et non corrigées directement). Pour chaque problème, le script vous indique la ligne correspondante (ce qui est très pratique). Voici la liste des choses qui sont vérifiées :

• Présence d'autant de balise ouvrantes que fermantes (détecte par exemple

"<gui><em>Test !<em></gui>")

• Un signe de ponctuation non précédé par une espace fine insécable (car la

substitution automatique ne touche pas à certains cas tendancieux)

• Présence d'une espace insécable (il est sensé en rester très peu voir

aucune après la correction automatique, c'est donc louche)

• Emploi d'un « B » dans une unité au lieu d'un « o » pour un octet

(d'après mon expérience, c'est une erreur assez fréquente chez les débutants)

3/ Le script applique les 2 points précédents uniquement sur les chaines traduites (blocs « msgstr »). Les commentaires et les chaines originales ne sont pas modifiés.

Voilà. J'ai testé le tout avec succès avec plusieurs .po officiels. Par exemple avec Rhythmbox (plus de 1200 chaines), je confirme n'avoir trouvé aucune erreur dans la correction automatique. De plus le script détecte 17 erreurs potentielles, mais il semble que seule une soit vraiment fondée (une espace insécable curieusement placée ligne 2426).

J'attends vos remarques et commentaires. Je suis également à l'écoute si vous avez des idées pour améliorer le script (d'autres types d'erreurs à vérifier par exemple).

Bon week-end, Nicolas

ps : (rappel) en attendant que ce bug soit officiellement résolu ( https://bugzilla.gnome.org/show_bug.cgi?id=626126 ), la manière la plus simple de reconnaitre une espace fine insécable d'une espace insécable dans gedit (par exemple) est de lancer une recherche sur le caractère souhaité. Celui-ci sera alors surligné dans tout le fichier.

    > Félicitation pour ton travail.
    > 
    > Parlons "politique" maintenant puisque tu y tiens. Il te
    > reste à me convaincre au sujet de tes histoires d'espace
    > fine
    > insécable avant une quelconque généralisation de la
    > procédure maintenant que cela me semble faisable grâce à
    > ton script :
    > 1) je m'étonne car dans tous les documents que j'ai trouvé,
    > il est dit que devant le symbole (:), il faut mettre un
    > espace insécable normal ???
    > 2) je n'ai trouvé aucun document officiel qui nous fixe les
    > règles en usage en français ???
    > 
    > Pourrais-tu me fournir des références officielles concernant
    > les règles en usage en France ?




    La règle est de mettre une espace fine insécable devant les
    signes de ponctuations doubles, c'est à dire devant les signes
    qui ont la hauteur d'un caractère (et donc devant les
    caractères :;!?» et «)

Tu ne m'as pas du tout convaincu. Les références ci-dessous ne sont même pas d'accord avec TA règle.

Ce n'est pas MA règle puisque d'autres sont du même avis. Et ce n'était qu'une proposition, si tout le monde préfère garder les espaces insécables devant les deux points, ça ne me pose pas de problème.

Si tu veux une autre source totalement arbitraire et subjective, j'ai ouvert la revu la plus proche de mon PC (Science & vie) et je constate que les deux points y sont systématiquement précédés par une espace fine.

Je parlais plutôt de source officielle (surtout pas wikipedia ou une université parmi une autre). Je peux te donner autant de page Web que tu m'en fourniras qui diront le contraire.

Je n'ai pas dit le contraire dans mon mail précédent. L'avantage de ce que je propose (emploi de la fine également devant les deux points) est aussi la simplicité/praticité car il n'y a alors pas besoin de jongler entre les différents types d'espaces.

Enfin c'est pas grave, je pense qu'il n'y a pas de règle (seul l'insécabilité est obligatoire) donc c'est une question d'esthétisme (qui ne se voit pas sur un ordinateur) donc pourquoi pas essayer avec un module. De toute façon personne ne viendra se plaindre si son espace est fine puisque cela ne se voit pas.

Je dois avoir un œil bionique pour voir la différence donc. C'est plutôt cool en fait. ^^

J'ai essayé de comprendre là où il n'y a rien à comprendre, désolé

Si c'est moi qui t'ai énervé, je m'en excuse.

Bon courage pour essayer de convaincre toutes les autres équipes... y compris Microsoft et MAC pour parler de la non minorité. J'espère seulement que cette histoire d'espace fine n'aura aucune incidence avec une quelconque compatibilité entre Windows et le reste.

...

C'est vrai qu'on est sur ce thread depuis un moment, donc admettons, je peux comprendre que ce qui a été dit au tout début ait été oublié.

Donc, pour rappel, si je vous propose ça c'est suite à des tests qui ont été effectués sur les principaux OS. Le compte rendu résultant se trouve ici : http://malaria.perso.sfr.fr/fines/fines.pdf

Pour résumer, il n'y a aucun problème de support de la fine avec les applications GTK, que ce soit sous GNU/Linux et Windows (testé sous XP, Vista et Seven). Par contre, les espaces fines sont affichées avec une taille nulle sous Mac OS (le bug a été rapporté). Je n'ai jamais caché ce dernier point, mais vu la quasi inexistence de la plateforme Gnome sous Mac et que ce bug est loin d'être bloquant... Au pire, ça contentera nos amis québécois, vu qu'ils n'utilisent pas d'espaces devant les signes de ponctuation (en informatique) ;-)

Nicolas

PS. : je vois avec Claude pour décider du (ou des modules) qu'on met à l'essai. On t'en informera lorsqu'on aura choisi.

    Quelques sources :

    Les règles typographiques de l'université Paris Diderot :
    http://www.eila.univ-paris-diderot.fr/sysadmin/gestion-docs/typo-francaise#ponctuation

    L'éditeur du fameux logiciel d'aide à la rédaction
    « Antidote » :
    http://www.druide.com/points_de_langue_13.html

    Enfin, la page « ponctuation » sur Wikipedia :
    http://fr.wikipedia.org/wiki/Ponctuation
    (si ça peut vous rassurer, je jure solennellement de ne pas
    avoir modifié cette page)


    Cependant, il est vrai que l'on trouve aussi des sources
    contradictoires concernant le symbole « : ».
    Je ne sais pas d'où vient ce « conflit ». Différents courants
    de pensée chez les typographes ?

    De ce point de vu là, je suis pour adopter une attitude
    pragmatique :

    - On rencontre les deux règles, donc on peut éventuellement
    admettre qu'aucune des deux ne peut être considérée comme
    étant foncièrement fausse (même si personnellement je suis
    pour l'espace fine devant les deux points, entre autre parce
    que je trouve ça plus esthétique).
    - Vu que les deux ponctuations sont possibles et que l'on doit
    utiliser l'espace fine insécable devant les autres signes de
    ponctuation double, il serait, je pense, plus pratique de
    l'utiliser également devant les deux points : cela nous
    évitera de jongler en permanence entre la fine et l'insécable
    classique, l'usage de cette dernière devenant alors très
    marginal.





    > Ensuite, pour répondre à ta question, je crois que nous
    > avons déjà décidé que nous étions prêt à faire un essai sur
    > un gros module de traduction pour voir si cela posait des
    > problèmes informatique, nous n'avons juste pas encore choisi
    > le module pour GNOME 3.0. Patience, on a encore quelques
    > mois.




    D'accord, sur le principe ça ne me pose aucun problème.


    Cordialement,
    Nicolas






    > Le 26 novembre 2010 20:16, Nicolas Delvaux
    > <nicolas.delvaux@gmx.com> a écrit :
    > 
    >         Salut à tous,
    >         
    >         voici encore une nouvelle version de mon script de
    >         correction/vérification des .po.
    >         
    >         Liste des nouveautés :
    >         
    >         - Le script est presque deux fois plus rapide ;
    >         - Le script détecte (et signal) maintenant si une
    >         chaine et sa traduction ne se terminent pas par le
    >         même signe de ponctuation ;
    >         - L'option « --ortho » à été améliorée
    >         
    >         Voilà pour cette fois. Pour le téléchargement, c'est
    >         toujours ici :
    >         http://malaria.perso.sfr.fr/francisator.tar.gz
    >         
    >         Je pense que le script commence à être mature,
    >         n'hésitez pas à vérifier vos .po avec son aide.
    >         
    >         Reste maintenant LA grande question : qu'en est-il
    >         des espaces fines insécables ?
    >         Vu que le script fait tout le boulot (et plus
    >         encore), je pense que la décision n'est plus que
    >         politique maintenant.
    >         
    >         
    >         Bonne soirée,
    >         Nicolas
    >         
    >         
    >         Le dimanche 21 novembre 2010 à 21:40 +0100, Nicolas
    >         Delvaux a écrit :
    >         
    >         > Salut à tous,
    >         > 
    >         > Suite à une discussion avec Bruno, j'ai le plaisir
    >         > de vous présenter une version nettement améliorée
    >         > de mon script de vérification/correction.
    >         > 
    >         > Voici les changements par rapport à hier :
    >         > 
    >         > - Beaucoup moins de « faux positifs » dans la
    >         > liste des erreurs « potentielles » (ça reste très
    >         > variable selon les .po) ;
    >         > - Chaque erreur vient avec son contexte (plus
    >         > besoin de naviguer entre le .po et la liste des
    >         > erreurs pour vérifier si une erreur est fondée ou
    >         > pas) ;
    >         > - Le script détecte (et signal) maintenant la
    >         > présence de plusieurs espaces à la suite ;
    >         > - La détection de la validité des balises XML a
    >         > été complétée et grandement améliorée ;
    >         > - L'indicateur d'avancement est maintenant plus
    >         > compréhensible ;
    >         > - Le diff entre le .po original et le .po corrigé
    >         > n'est plus généré automatiquement (c'était assez
    >         > inutile et c'est facilement faisable manuellement
    >         > si besoin).
    >         > 
    >         > De plus, vous pouvez maintenant rajouter
    >         > « --ortho » en argument sur la ligne de commande
    >         > pour qu'un fichier ne contenant que les chaines
    >         > traduites soit créé.
    >         > Ça permet de gagner du temps si vous souhaitez
    >         > chasser les fautes d'orthographe avec un éditeur
    >         > de texte. (au début il faudra tout de même lui
    >         > dire d'ignorer certains mots, mais il ne faut le
    >         > faire qu'une seule fois à priori).
    >         > 
    >         > 
    >         > Voilà, ça me parait déjà pas mal.
    >         > Je précise aussi que ce script est sous licence
    >         > BSD, chacun peut l'adapter et le redistribuer
    >         > comme bon lui semble.
    >         > Cependant, vu que ce script pourrai également
    >         > servir à d'autres équipes de traducteurs, il
    >         > serait tout de même souhaitable de centraliser les
    >         > améliorations/corrections.
    >         > (si besoin, il devrait-être possible de l'héberger
    >         > sur traduc)
    >         > 
    >         > Le script peut toujours être téléchargé à la même
    >         > adresse :
    >         > http://malaria.perso.sfr.fr/francisator.tar.gz
    >         > 
    >         > 
    >         > Bonne soirée !
    >         > Nicolas
    >         > 
    >         > 
    >         > Le samedi 20 novembre 2010 à 17:58 +0100, Nicolas
    >         > Delvaux a écrit :
    >         > 
    >         > > Salut à tous,
    >         > > 
    >         > > Chose promise, chose due voici le fameux script
    >         > > dont nous parlions la semaine dernière :
    >         > > http://malaria.perso.sfr.fr/francisator.tar.gz
    >         > > Je vais essayer de vous dire tout ce qu'il faut
    >         > > savoir de manière concise (c'est pas gagné :-p).
    >         > > 
    >         > > Dans l'archive sur lequel pointe le lien
    >         > > ci-dessus, vous trouverez deux choses :
    >         > > - le script en lui même (francisator.sh)
    >         > > - un fichier de test (test.po)
    >         > > 
    >         > > Vu qu'il peut-être très pénible de vérifier tout
    >         > > ce que fait le script sur des fichier .po de
    >         > > plusieurs milliers de lignes, il est beaucoup
    >         > > plus commode d'utiliser un fichier de test pour
    >         > > mettre le script à l'épreuve.
    >         > > Libre à vous de modifier/compléter ce fichier
    >         > > test en y mettant les situations les plus
    >         > > improbables que le script pourrait jamais
    >         > > rencontrer (enfin il faut tout de même que ça
    >         > > reste un fichier .po valide ;-)).
    >         > > 
    >         > > Que fait le script ?
    >         > > 
    >         > > 1/ Il corrige directement les espaces devant les
    >         > > signes de ponctuation qui vont bien (il remplace
    >         > > les espace et les espaces insécables par des
    >         > > espaces fines insécables)
    >         > > → vu qu'il s'agit d'une correction automatique,
    >         > > c'est bien sûr cette partie qui doit être
    >         > > particulièrement testée. D'après mes tests elle
    >         > > est 100% fiable. Tous les pièges cités par Bruno
    >         > > la semaine dernière sont déjoués (et ce ne sont
    >         > > pas les seuls).
    >         > > L'intérêt est de pouvoir faire confiance à cette
    >         > > partie du script : s'il faut examiner
    >         > > attentivement des diff de corrections de
    >         > > plusieurs centaines de lignes à chaque fois, ça
    >         > > n'a aucun intérêt.
    >         > > Utilisez le fichier test pour vous convaincre de
    >         > > sa fiabilité et/ou trouver des bugs qui
    >         > > m'auraient échappé !
    >         > > 
    >         > > 
    >         > > 2/ Le script vérifie également la présence de
    >         > > certaines erreurs *potentielles*. Notez bien que
    >         > > vu que ces erreurs sont potentielles, elles ne
    >         > > sont que *signalées* (et non corrigées
    >         > > directement).
    >         > > Pour chaque problème, le script vous indique la
    >         > > ligne correspondante (ce qui est très pratique).
    >         > > Voici la liste des choses qui sont vérifiées :
    >         > > - Présence d'autant de balise ouvrantes que
    >         > > fermantes (détecte par exemple
    >         > > "<gui><em>Test !<em></gui>")
    >         > > - Un signe de ponctuation non précédé par une
    >         > > espace fine insécable (car la substitution
    >         > > automatique ne touche pas à certains cas
    >         > > tendancieux)
    >         > > - Présence d'une espace insécable (il est sensé
    >         > > en rester très peu voir aucune après la
    >         > > correction automatique, c'est donc louche)
    >         > > - Emploi d'un « B » dans une unité au lieu d'un
    >         > > « o » pour un octet (d'après mon expérience,
    >         > > c'est une erreur assez fréquente chez les
    >         > > débutants)
    >         > > 
    >         > > 3/ Le script applique les 2 points précédents
    >         > > uniquement sur les chaines traduites (blocs
    >         > > « msgstr »). Les commentaires et les chaines
    >         > > originales ne sont pas modifiés.
    >         > > 
    >         > > Voilà.
    >         > > J'ai testé le tout avec succès avec
    >         > > plusieurs .po officiels.
    >         > > Par exemple avec Rhythmbox (plus de 1200
    >         > > chaines), je confirme n'avoir trouvé aucune
    >         > > erreur dans la correction automatique. De plus
    >         > > le script détecte 17 erreurs potentielles, mais
    >         > > il semble que seule une soit vraiment fondée
    >         > > (une espace insécable curieusement placée ligne
    >         > > 2426).
    >         > > 
    >         > > 
    >         > > J'attends vos remarques et commentaires.
    >         > > Je suis également à l'écoute si vous avez des
    >         > > idées pour améliorer le script (d'autres types
    >         > > d'erreurs à vérifier par exemple).
    >         > > 
    >         > > Bon week-end,
    >         > > Nicolas
    >         > > 
    >         > > 
    >         > > ps : (rappel) en attendant que ce bug soit
    >         > > officiellement résolu
    >         > > ( https://bugzilla.gnome.org/show_bug.cgi?id=626126 ), la manière la plus simple de reconnaitre une espace fine insécable d'une espace insécable dans gedit (par exemple) est de lancer une recherche sur le caractère souhaité. Celui-ci sera alors surligné dans tout le fichier.