Au sujet de l'espace fine insécable...

Jeu 5 Aou 19:14:14 UTC 2010

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

Mais je ne demande pas mieux :)

(le but est aussi de rapporter les bugs correspondants en cas de
problème)

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

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

> > 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 :
> > https://bugs.launchpad.net/rosetta/+bug/608631/comments/16
> > (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).

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

Tiens, il en parle ici (en anglais par contre) :
https://bugs.launchpad.net/rosetta/+bug/608631/comments/10

Je me permet de copier la partie intéressante (désolé, j'ai la flemme de
traduire ;)) :

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

Bref, fondamentalement le problème n'est pas dans les polices (même si
ça aide au niveau de la compatibilité).

> > > > 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 <http://listes.traduc.org/mailman/listinfo/traduc>
> 

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)

> > 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) : http://malaria.perso.sfr.fr/fines.html )
> 
> Marche pas dans Lynx. Dans un terminal le nnbsp est tout simplement ignoré et 
> la ponctuation se retrouve collée au mot.

Ce n'est pas lié au terminal (dans le sens où si tu fais un echo avec un nnbsp ça fonctionne)

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

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

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)

> > En toute rigueur c'est certes incorrect, mais c'est à mon sens moins
> > grave.
> 
> Non. ;)

Du coup je suis d'accord ;-)

Nicolas
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <https://lists.ubuntu.com/archives/ubuntu-fr-l10n/attachments/20100805/6f293a6d/attachment.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: face-wink.png
Type: image/png
Taille: 876 octets
Desc: non disponible
URL: <https://lists.ubuntu.com/archives/ubuntu-fr-l10n/attachments/20100805/6f293a6d/attachment.png>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: face-smile.png
Type: image/png
Taille: 873 octets
Desc: non disponible
URL: <https://lists.ubuntu.com/archives/ubuntu-fr-l10n/attachments/20100805/6f293a6d/attachment-0001.png>