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) ?
Et bien disons que tu l'as dis toi même (en semblant d'accord) dans ton dernier mail, c'est purement esthétique.
Partant de là, je ne suis pas revenu sur le sujet, vu qu'il me semblait réglé.
Je suis d'accord pour dire que ce n'est pas une révolution qui va faire exploser la part de marché de Gnome, mais du moment qu'on réussi à réduire les « risques » et inconvénients au maximum, je ne vois pas pourquoi on ne le ferait pas.
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.
Pourrais-je avoir accès à ce script ? Je gagnerais déjà pas mal de temps.
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 ?
Ce n'est pas un problème. On dépassera certes la dizaine de ligne que j'envisageais, mais je crois en l'infinie puissance des expressions régulières. ;-)
Pour l'histoire des smileys, on pourrait simplement envisager de faire le remplacement sur " : " (pour milieu de chaine) ou sur " :"" (pour la fin de chaine).
Tout ça pour dire que c'est techniquement possible, on trouvera toujours un moyen.
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...
Au départ j'envisageais juste un script de conversion qui viendrait en plus du ou des scripts de corrections des erreurs usuelles, mais si je comprends bien tu préfèrerais tout fusionner en un seul.
C'est tout aussi faisable sur le principe.
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.
C'est certes un cas à gérer.
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é.
On est sûr que l'espace fine insécable doit être utilisée devant les caractères "?;!:»" et derrière "«".
Quelques sources (dont les règles typographiques actuelles de Gnome) disent qu'il faut une espace insécable classique devant ":»" et derrière "«", ce qui est par exemple en contradiction avec wikipedia et les recommandation de l'université Paris Diderot : http://www.eila.univ-paris-diderot.fr/sysadmin/gestion-docs/typo-francaise#ponctuation
Partant de là je me dis qu'il serait plus pratique d'utiliser les espaces fines avec ces caractères également, ça évite d'avoir à jongler en permanence (l'espace insécable n'étant alors utilisée que très rarement).
Pour les unités, en fait la solution était sous notre nez : http://www.utc.fr/~tthomass/Themes/Unites/typographie/Typo.pdf
(lien donné ici : http://traduc.org/gnomefr/Typographie )
L'espace fine doit donc être utilisée comme séparateur entre les unités et comme séparateur entre les nombres (donc aussi valable pour les numéros de téléphone et les codes postaux comme « 42 240 », même s'il y a peut de chances qu'on en rencontre dans le contexte qui nous intéresse ici ;-))
Bref, l'espace insécable classique ne doit être utilisée que dans les noms composés et et après des abréviations comme M. ou Mme. Michu.
Je n'ai pas trouvé de document corroborant ce dernier point, mais ça me paraitrait logique. Après, sachant que ces chaines sont rares, si on ne veux pas s'embêter on pourrais également utiliser des fines dans ce cas. Je ne suis pas spécialement pour, mais c'est envisageable. À vous de voir.
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...
Ça ne me dérangerais pas d'essayer, ce genre défi m'amuse ^^
Dans le pire des cas, ce n'est pas l'aide sur les forums qui manque.
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.
Sous gedit, le symbole utilisé pour représenter la fine est le même que pour l'espace insécable.
On peut rapporter un bug si nécessaire.
Quand à Lokalise, l'espace fine est prise en compte, mais elle est affichée avec une largeur nulle (à cause d'un bug dans Qt). Beaucoup de gens traduisent Gnome avec Lokalise ?
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...
Cliquer sur le bouton « rechercher le suivant » ?
Après c'est pas le mode manuel pour rien, l'idéal serait en effet un script.
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.
Tu dis qu'on en est à à peu près 50% pour la 3.0, donc d'ici 4 mois ça fera déjà un bon morceau.
S'il subsiste une légère cohabitation pendant quelques temps, je ne pense pas que ça soit un problème vu que la différence entre les deux caractère n'est pas non plus énorme (je ne pense pas que ça dérangera les utilisateurs).
Les commiteurs ont un accès git sur tous les projets
ok
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 :-) )
Donc je veux bien m'y coller.
Il faudrait donc que j'ai accès au(x) script(s) que tu utilises (histoire de ne pas réinventer la roue) et que tu me fasses une sorte de micro cahier des charges.
Tu veux que le script te demande confirmation avant chaque substitution ? Tu veux qu'il fasse tout directement, quitte à t'afficher un diff entre les deux versions ?
Du coup je ne te dis pas que j'aurais fini en 5 minutes (contrairement aux apparences, j'ai également une vie à côté de ça ^^) mais ça reste faisable.
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 ?
Donc sur le principe je suis d'accord.
Bon dimanche,
Nicolas