Le 13 mai 2016 à 13:38, José Fournier <jaaf64@zoraldia.com> a écrit :

Bonjour à tous,

J'ai travaillé sur un script python purificateur typographique des
fichiers po pour la partie traduction. Rien à voir avec la première idée
que j'avais soumise à Jean-Baptiste et qui « marchouillait » — ou ne
marchait pas dans certains cas. J'avais encore – et j'ai toujours mais
moins – beaucoup de choses à apprendre sur python et les regex.

Le nouveau script est assez interactif et assez facile à utiliser,
permet de contrôler ce qu'on fait et n'est pas destructif (travaille par
duplication du dossier). Il permet aussi de coloriser les différents
types d'espaces: sécable, insécable, fine, fine insécable si besoin
avant de se prononcer sur une substitution.

Il suppose une importation des fichiers po depuis Zanata. Il travaille
par balayage de tous les messages de tous les fichiers en se contentant
de répliquer les messages en anglais. Les messages en français qui ne
sont pas concernés par une correction sont également répliqués tels
quels. On applique toutes les règles à un message avant de passer au
suivant. Il n'y a donc normalement qu'une seule passe.

Je pense être arrivé à un résultat qui va permettre d'expurger – et
avec un grand confort– les fichiers po du guide d'installation d'un
certain nombre d'erreurs, ou d'options que j'ai prises et qui pourraient
ne pas être partagées.

Avant de l'appliquer, pour effectuer une pré-correction, il faudrait que
nous soyons d'accord sur un certains nombre de règles qui ne sont pas
forcément absolues (des solutions différentes existant selon les
organismes de référence – le mien étant plutôt, l'Imprimerie nationale
(IN) mais pas toujours.

Voici ces règles :

Le mieux est de donner le numéro d'options que vous préférez (quand
option il y a) et dire ok ou non pour les autres

Bien sûr, il y aura plein d'exceptions à ces règles – d'où la nécessité
d'interactivité pour contrôler – en particulier dans les expressions
liées à l'informatique (http:,   &PRODUCT;, etc.

1 Espace fine insécable devant ;, !, ?

2 Espace mot (non fine) insécable devant :

3 Pas d'espace avant les ponctuations simple (. et ,)

4-a Espace mot (non fine) insécable entre « et le texte qui suit (IN)
4-b Espace fine insécable entre « et le texte qui suit (assez fréquent)

5-a Espace mot insécable entre » et le texte qui précède (IN)
5-b Espace fine insécable entre » et le texte qui précède (assez fréquent)

6 Pas d'espace entre les parenthèses et le texte inclus (fermante et
ouvrante)

7 Pas d'espace entre les crochets [ et ] et le texte inclus (fermant et
ouvrant)

8 Espace mot (sécable) à l'extérieur des parenthèses et des crochets
(sauf si une ponctuation les suit

9 Pas d'espace autour du trait d'union (touche 6)

10 Le tiret qui tient lieu de parenthèse est un tiret semi-cadratin (–)
pas un trait d'union (-). Il disparait devant le point final d'une
phrase. Il est séparé des deux côtés par :
10-a une espace mot (sécable) (IN)
10-b une espace fine sécable (rare)

11 L'apostrophe n'est jamais séparée

12 Le / dans un texte est séparé des deux côtés par une:
12-a espace fine insécable
12-b espace mot insécable

13 Caractère … et non pas trois caractères . (...)

14 etc. et non pas etc… ou etc...

15 En fin de phrase etc. pas etc..

Je peux formaliser tout ça – si ce n'est pas déjà fait – avec d'autres
règles de traduction, sur une page de wiki si vous en êtes d'accord.
Cette liste peut être complétée.

Merci de me donner votre avis

Bonjour José,

L'automatisation me plait en général, et en particulier sur ce cas.

Ce qui me plairait aussi serait de voir le code de ton outillage pour ce faire, et surtout de valider chacun des cas cités par des tests.

Voire même idéalement de permettre à cet outillage d'être multilangue (chaque langue ayant ses règles de typographie, et permettrait par exemple de remonter les problèmes sur les chaînes source), que chaque règle soit un greffon, et que ces greffons soient débrayables, pour permettre son utilisation sur des projets divers et variés.

Une autre information importante à mon sens pour les traducteurs, au delà des règles elles-mêmes, est l'indication de comment taper ces caractères spéciaux sur un clavier Linux (la combinaison de touches, quoi).

Et vu que l'on risque d'utiliser des caractères UTF-8, préciser que l'outil devra prendre en entrée des .po en UTF-8, et tourner dans un environnement UTF-8. Sinon les résultats risquent d'être intéressants :)

Si tu as un compte github ou autre gitlab, je suis curieux de jeter un œil.

Cdt,

Jérôme Fenal