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