<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> <BLOCKQUOTE TYPE=CITE> <PRE> > > La discussion soulève les problèmes d'utilisation de l'espace fine > > insécable : > > > > * pas forcément présente dans toutes les polices / jeux de caractères > > * pas forcément correctement interprétée par les agents utilisateurs > > (navigateurs Web, afficheur d'aide, etc.) > > Effectivement, mais il est également dis que cela relève globalement du > passé maintenant. Je pense qu'il va falloir une démonstration technique un peu plus solide. :) </PRE> </BLOCKQUOTE> <PRE> Mais je ne demande pas mieux <IMG SRC="cid:1281030778.10099.43.camel@nicolas-home" ALIGN="middle" ALT=":)" BORDER="0"> </PRE> (le but est aussi de rapporter les bugs correspondants en cas de problème) <PRE> </PRE> <BLOCKQUOTE TYPE=CITE> <PRE> > J'ai moi même effectué plusieurs test, même sous windows, et je n'ai pas > eu de problème. > Ça fonctionne même sous IE ! (je n'ai pas pu tester avec autre chose que > le 8) Oui mais bon nos traductions ne sont pas censées être utilisées sous Windows ;) Il faudrait tester dans Yelp, dans les navigateurs basés sur Webkit, dans un tty, dans une interface en GTK, en Qt, etc. Et comme visiblement cela ne semble pas marcher dans un terminal, je crois qu'il vaut mieux abandonner cette idée. </PRE> </BLOCKQUOTE> Jusqu'à présent je n'ai pas eu de problème en GTK. J'avoue ne pas avoir encore eu le temps d'essayer en Qt et avec Yelp. Il faudrait donc aussi tester avec Webkit, c'est bizarre que ça fonctionne avec Chromium mais pas avec Safari... Et si, ça marche dans le terminal (type xterm). (cf plus bas pour ton problème avec lynx) Par contre je viens de tester à l'instant et je suis bien obligé d'admettre que ça ne fonctionne pas dans les TTY, les nnbsp sont affichés comme des carrés penchés (j'aimerais bien savoir pourquoi ce symbole en particulier, c'est étrange). <BLOCKQUOTE TYPE=CITE> <PRE> > Le seul cas où j'ai rencontré un bug lié aux espaces fine insécables, > c'était avec firefox avec une police monospace. > Par exemple ici : > <A HREF="https://bugs.launchpad.net/rosetta/+bug/608631/comments/16">https://bugs.launchpad.net/rosetta/+bug/608631/comments/16</A> > (pas de différence avec FF, ça marche avec chromium et IE) Forcément avec une police à chasse fixe tous les caractères ont la même largeur... Il faut tester avec de nombreuses polices. La plupart contiennent le caractère thinsp (U+2009 sans prendre en compte qu'il devrait être insécable) mais peu contiennent le caractère nnbsp (U+202F). </PRE> </BLOCKQUOTE> <PRE> Comme l'avait expliqué verdy_p, ce n'est pas un problème de police. (il est plus pointu que moi techniquement, je lui avais dit de venir participer ici mais bon...) </PRE> Tiens, il en parle ici (en anglais par contre) : <A HREF="https://bugs.launchpad.net/rosetta/+bug/608631/comments/10">https://bugs.launchpad.net/rosetta/+bug/608631/comments/10</A> Je me permet de copier la partie intéressante (désolé, j'ai la flemme de traduire <IMG SRC="cid:1281032458.10099.72.camel@nicolas-home" ALIGN="middle" ALT=";)" BORDER="0">) : <BLOCKQUOTE TYPE=CITE> Unfortunately, in the latest Microsoft fonts for Windows Seven, Microsoft decided to drop this character from its best font for UI "Segoe UI" (despite it was present since now very long in Times New Roman, and Arial). Why ? because the character is handled automatically in the OS'es builtin text renderers, and reuses automatically the same glyph as "THINSP", treating it as unbreakable for layout purpose, because it is part of the layout engine. Fontss DO NOT need to include such duplicate mapping for the same glyph as they can't manage themselves the unbrealable properties (so even the mapping of NBSP is completely unneeded: the renderer will use the glyph and metrics asigned to standard SPACE). </BLOCKQUOTE> Bref, fondamentalement le problème n'est pas dans les polices (même si ça aide au niveau de la compatibilité). <BLOCKQUOTE TYPE=CITE> <PRE> > > > Celui-ci a pour objectif d'implémenter un tag similaire à [nbsp] pour > > > l'espace fine insécable. > > > Le problème c'est que les devs n'ont pas envie d'implémenter une telle > > > chose tant que l'espace fine n'est pas suffisamment utilisé. > > > > > > J'aimerais donc connaitre votre avis sur le sujet et si vous seriez > > > éventuellement prêt à changer vos règles pour recommander l'usage de la > > > fine à la place de l'insécable classique. > > > > AMHA ce n'est pas une bonne idée. Outre les contraintes techniques > > évoquées, l'habitude a été prise depuis des années par les équipes de > > traductions d'utiliser l'espace insécable. Cela exigerait de modifier > > des milliers de traductions sans garantie de résultat. > > (c'est si terrible pour nos habitudes de passer de « AltGr+Maj+Espace » > à « AltGr+v » ?) Le problème n'est pas là. Cela ne me parait envisageable que si tout le monde adopte cette règle. La masse de traductions effectuées sur Launchpad est somme toute assez marginale par rapport au travail effectué en amont (GNOME, KDE, TP, Debian,...). Claude t'as suggéré à juste titre d'en discuter avec la liste traduc.org <<A HREF="http://listes.traduc.org/mailman/listinfo/traduc">http://listes.traduc.org/mailman/listinfo/traduc</A>> </PRE> </BLOCKQUOTE> Effectivement, j'en parlerais là bas aussi. (mais je ne me fais pas trop d'illusions, si je n'arrive pas à convaincre ici, convaincre toutes les équipes en même temps ne sera pas facile) <BLOCKQUOTE TYPE=CITE> <PRE> > Les fines sont tout de même reconnaissable par rapport aux espaces > classiques. > (par exemple, voir le lien ci-dessus avec autre chose que Firefox, ou > encore ce lien (même avec FF) : <A HREF="http://malaria.perso.sfr.fr/fines.html">http://malaria.perso.sfr.fr/fines.html</A> ) Marche pas dans Lynx. Dans un terminal le nnbsp est tout simplement ignoré et la ponctuation se retrouve collée au mot. </PRE> </BLOCKQUOTE> <PRE> Ce n'est pas lié au terminal (dans le sens où si tu fais un echo avec un nnbsp ça fonctionne) </PRE> Évidemment, les terminaux utilisent traditionnellement des polices à chasse fixe donc on ne vois pas la différence avec un espace normal. Le problème que tu décris semble plus lié au moteur de rendu de Lynx, pas au terminal en lui même. <BLOCKQUOTE TYPE=CITE> <PRE> > Pour les points de suspensions, la différence est moindre entre les > deux. > il n'y a quasi aucune différence entre … et ... Affiche ton message avec une police à chasse fixe tu aura une vrai différence visuelle ;) Il y a une différence de taille entre utiliser un caractère et en utiliser trois. </PRE> </BLOCKQUOTE> Effectivement. D'où la aussi mon incompréhension, pourquoi alors conseiller les 3 points ? Si ça ne tenait qu'à moi je me tiendrais simplement aux règles typographiques françaises. Certes, il y aurait peut-être quelques bugs (et je continue de croire, peut-être naïvement, qu'ils seraient minimes maintenant que l'UTF-8 se généralise) mais je ne les contournerais pas en utilisant les mauvais caractères (ou alors juste temporairement et ponctuellement, à l'endroit précis où ça bug en attendant que ça soit résolu). Quitte à faire des traductions, je préfèrerais qu'elles soient les plus parfaites possibles. Et puis ça valoriserait à la fois notre langue, notre travail et les logiciels libres en eux même (enfin c'est mon opinion). Mais une telle position est intenable seul, je serais donc contraint de me ranger à l'avis général. (mais j'aurais essayé au moins) <BLOCKQUOTE TYPE=CITE> <PRE> > En toute rigueur c'est certes incorrect, mais c'est à mon sens moins > grave. Non. ;) </PRE> </BLOCKQUOTE> <PRE> Du coup je suis d'accord <IMG SRC="cid:1281032458.10099.72.camel@nicolas-home" ALIGN="middle" ALT=";-)" BORDER="0"> </PRE> Nicolas </BODY> </HTML>