---------- Message transféré ---------- De : annoa.b@gmail.com annoa.b@gmail.com Date : 14 novembre 2010 13:07 Objet : Re: [Gnomefr] Adopter l'espace fine insécable ? À : Nicolas Delvaux nicolas.delvaux@gmx.com

Le 14 novembre 2010 00:28, Nicolas Delvaux nicolas.delvaux@gmx.com a écrit :

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 clair, tu ne veux pas discuter du gain car tu sais pertinemment qu'il n'y a aucun espoir de nous convaincre (voir mon commentaire sur les paragraphes justifiés) ? Pourquoi ne fais-tu pas une enquête auprès de la population pour savoir si les gens s'en foutent ou pas (c'est peut-être déjà fait ?) Il n'y a aucune honte à avoir un cheval de bataille personnel. Si les gens réclament cette espace fine alors let's go !

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...

Quand on sait que presque tous les nouveaux traducteurs ne prennent pas en

compte les consignes... En plus d'oubli naturel des autres (moi inclus) ....

oui c'est grosso-modo juste cela, en gros faudra qu'on revérifie tout (je le fais déjà pour les espaces insécables avec un script et crois-moi, cela me prend déjà pas mal de temps de corriger ces petites erreurs. Par exemple, que fais tu lorsque, dans le texte, il y a un smileys ;-) (espace insécable devant avec ton script ?) que fais-tu quand, par erreur ou pas, il se trouve qu'il y a un espace devant un ; dans le texte anglais, il sera converti par ton script ?

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.

Non par forcément. Effectivement, il y a déjà deux cas : lorsque l'espace initial est insécable et lorsqu'il ne l'est pas. J'avais oublié... En fait trois cas, lorsque le traducteur a oublié de mettre un espace...

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. ;-)

Non Dans cet exemple, je voulais signaler un cas particulier ou l'espace (insécable ou pas) se trouve sur la ligne d'AVANT. Je ne pense pas que msgcat puisse faire cela (???) mais un traducteur peut le faire... avec ses petits doigts

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).

Il te semble... (et pour M. Dupond ? et pour les autres cas ?) Une étude plus sérieuse me semble nécessaire de tous les cas d'espace insécable (fine ou pas) pour écrire un script qui tienne la route. Tu as encore un peu de travail sur la planche, désolé. En tous cas tu es d'accord, cela ne peut pas être un simple remplacement des espaces insécables, ouf !

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.

Aisément, surement mais pas pour moi, je suis traducteur pas programmeur et pour être sûr que tous les cas sont pris en compte...

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.

Il faut bien déjà vérifier que les espaces insécables sont correctement

mis. Admettons qu'un fichier po respecte les espaces fines, de nouvelles chaînes arrivent et sont traduites : 1) il faut vérifier que les espaces insécables (fines ou pas) sont bien mis 2) il faut appliquer ton script systématiquement et pour la fin des temps puis que lorsqu'on regarde un diff, on ne voit pas de différences entre fine ou pas... (cela rejoint mes commentaires plus bas)

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 ?

Sous gedit, il y a un greffons pour les visualiser par un symbole grisatre différent (même si depuis la 10.10, il ne marche plus comme avant et cela m'énerve un peu d'ailleurs) , sous Lokalize (il sont d'une couleur très très trop légèrement différente à mon goût), c'est tout ce que je connais.

Est-ce qu'ils font une distinction entre fine ou pas, j'en sais rien, je te laisse le découvrir ? mais cela serait bien.

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.

simple, pas si le fichier fait quelques milliers de lignes... j'en ai mal à la molette d'avance...

-- 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 !

Ah bonne nouvelle, ce n'était pas clair à mes yeux

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.

Voir le site mais actuellement pour passer à la 3.0 il y a une trentaine de fichiers (soit à la louche 50 %)

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. :-)

Et cela fait un truc bancal... moitié fine, moitié pas fine.

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.

Les commiteurs ont un accès git sur tous les projets

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 ?

Pour le script puisque cela a l'air si SIMPLE, qu'attends tu pour nous en proposer un ? (n'attends aucune clémence de ma part, au moindre bug, je pense que tu passeras un sale quart-d'heure :-) )

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).

NON, car il y aura toujours des gens qui traduiront sans espace insécable et cela fera deux lignes supplémentaires de test dans mon script... ;-) et des modifs en plus.

En résumé : partant d'un script qui convertit correctement les fichiers po ("espace:", "espaceinséc:", ...) en ("espaceinsécfine:, ...) en faisant attention à tous les cas particuliers que j'ai soulevé (mais il y en a peut-être d'autre) 1) ne pas toucher à la chaînes originale et aux commentaires 2) faire attention au espace (insec ou pas) en fin de ligne (donc suivi de ") si la ligne suivante commence pas (":" ou "?", ...) 3) attention aux smileys 4) ...

et d'un éditeur qui m'affiche clairement la différence entre les espaces, insécables ou pas, fines ou pas, tout devient possible.

Tout est possible en informatique

Donc ok pour un test sur un gros module ?

Bruno

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