---------- 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 :
- 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
annoa.b＠gmail.com