Salut à tous,
je ne sais pas si vous êtes au courant, mais en toute rigueur nous sommes sensé utiliser des espaces fines insécables en lieu et place des espaces insécables. Avec l'agencement français par défaut (du moins sous Ubuntu), on peut en entrer un via « Alt Gr + v ».
Actuellement les espaces fines ne sont pas utilisées pour des raisons « historiques » et simples : la technique ne suivait pas.
Étant persuadé que la situation a évolué et/ou que l'on devrait s'atteler à rapporter et corriger les bugs correspondants plutôt que d'attendre qu'ils se résolvent par eux même, j'ai rédigé un petit rapport sur l'état du support de l'espace fine insécable dans le monde du logiciel libre. Vous pouvez le télécharger ici : http://malaria.perso.sfr.fr/fines/fines.pdf
Comme vous pourrez le constater, il y a de bonnes et de mauvaises surprises.
Les bonnes : la plateforme Gnome et les logiciels Mozilla Les mauvaises : Qt/KDE et les TTY
Je compte sur votre coopération pour compléter ce rapport avec d'éventuels autres tests qui s'avéreraient pertinents (peut-être, entre autre, sur Mac OS et BSD) et pour rapporter les bugs qui ont été mis en exergue (car je manque aussi de connaissances techniques, sur Qt entre autre). Pour vous aider, sachez que les sources (et donc les captures d'écran) sont disponibles à l'adresse suivante : http://malaria.perso.sfr.fr/fines/
Merci d'avance pour votre intérêt.
Nicolas
Afficher les réponses par date
Bonjour Nicolas,
en toute rigueur nous sommes sensé utiliser des espaces fines insécables en lieu et place des espaces insécables.
Je suppose que tu parles de U+202F NARROW NO-BREAK SPACE (présent dans Unicode depuis version 3.0) et U+00A0 NO-BREAK SPACE ?
Les mauvaises : Qt/KDE et les TTY
Pour les TTY (fixed-width font), les résultats ne m'étonnent pas trop: Tu demandes au terminal d'interpréter un "NARROW NO-BREAK SPACE" comme ayant largeur 0 ou 1. Certains choisissent de lui assigner une largeur de 0, d'autres de 1. Si on ne veut pas que le terminal résolve cette ambiguité, il faut la résoudre nous-même, donc utiliser où U+00A0 NO-BREAK SPACE où U+FEFF ZERO WIDTH NO-BREAK SPACE.
Bruno
Bonjour,
en toute rigueur nous sommes sensé utiliser des espaces fines insécables en lieu et place des espaces insécables.
Je suppose que tu parles de U+202F NARROW NO-BREAK SPACE (présent dans Unicode depuis version 3.0) et U+00A0 NO-BREAK SPACE ?
Effectivement, j'aurais peut-être dû le préciser (c'est toujours les choses les plus élémentaires que l'on oublie)
Les mauvaises : Qt/KDE et les TTY
Pour les TTY (fixed-width font), les résultats ne m'étonnent pas trop: Tu demandes au terminal d'interpréter un "NARROW NO-BREAK SPACE" comme ayant largeur 0 ou 1. Certains choisissent de lui assigner une largeur de 0, d'autres de 1. Si on ne veut pas que le terminal résolve cette ambiguité, il faut la résoudre nous-même, donc utiliser où U+00A0 NO-BREAK SPACE où U+FEFF ZERO WIDTH NO-BREAK SPACE.
C'est en effet une solution, mais il s'agit plus pour moi de dépannage en attendant une résolution du bug sous-jacent.
En effet il serait beaucoup plus simple pour les traducteurs d'utiliser des espaces fines insécables partout plutôt que de se demander à chaque fois si la chaine en question sera affichée dans un terminal et donc si on doit utiliser une espace insécable en substitution.
En ce qui concerne les TTY en eux même, le problème c'est qu'ils ne choisissent pas entre une taille 0 et une taille 1 (on pourrait même passer outre une taille 0 je pense) mais qu'ils choisissent une 3ème voie farfelue : afficher un losange à la place. (va dans un TTY et tape « Alt Gr + v » pour le voir de tes yeux) Et puis sachant que l'écrasante majorité des autres terminaux se comportent très bien...
J'imagine de plus qu'un patch faisant grosso modo comprendre aux TTY que, au niveau de l'affichage, « espace fine insécable = espace insécable » serait assez simple à implémenter et règlerait notre problème (même si c'est faux, sémantiquement)
Le hic c'est que je ne sais pas contre quel logiciel rapporter ce bug : je ne sais pas quel programme « fournit » les TTY (ou du moins gère leurs rendus de textes).
Nicolas
ps : Au sujet des polices à chasse fixe, certains disent que si la sémantique du caractère est d'être plus fin, alors il doit effectivement être affiché plus fin. En clair, la chasse fixe ne devrait pas primer sur la sémantique. C'est un autre problème, je veux bien qu'on en reparle quand tout le reste sera réglé ^^
Le 24/08/2010 11:44, Nicolas Delvaux a écrit :
C'est un autre problème, je veux bien qu'on en reparle quand tout le reste sera réglé ^^
on pourrait aussi se préoccuper de savoir si ce genre de détail a le moindre intérêt quand il reste des centaines de documents non traduits.
jdd
Le mardi 24 août 2010 à 12:19 +0200, jdd a écrit :
C'est un autre problème, je veux bien qu'on en reparle quand tout le reste sera réglé ^^
on pourrait aussi se préoccuper de savoir si ce genre de détail a le moindre intérêt quand il reste des centaines de documents non traduits.
Il s'agit « juste » d'améliorer les traductions actuelles et à venir ;-) En soit, la correction des bugs restant ne rentre pas en conflit avec les travaux de traductions, ce sont des taches à effectuer en parallèle.
Et, quand on en sera à ce point (quoi que déjà envisageable pour les programmes en GTK et les logiciels Mozilla), la « migration » des traductions se fait simplement à coups de « chercher/remplacer tous » dans les fichiers correspondants.
(Après je ne sais pas si tu faisais référence aux espaces fines en général ou juste à la potentielle inconsistance des polices à chasse fixe)
Nicolas
Le 24/08/2010 12:45, Nicolas Delvaux a écrit :
(Après je ne sais pas si tu faisais référence aux espaces fines en général ou juste à la potentielle inconsistance des polices à chasse fixe)
aux espaces fines... le concept du beau, tel qu'il est traditionnel dans la typographie me parait davantage relever du musée que de la vie courante. C'est plus un boulet qu'un acquis.
Il est déjà souvent bien difficile de garder un(e?) espace avant les ;:!? et quand par malheur tout ca se retrouve dans une URL (titre de page html), on frise l'apoplexie :-)
jdd
Le mardi 24 août 2010 à 12:57 +0200, jdd a écrit :
Le 24/08/2010 12:45, Nicolas Delvaux a écrit :
(Après je ne sais pas si tu faisais référence aux espaces fines en général ou juste à la potentielle inconsistance des polices à chasse fixe)
aux espaces fines... le concept du beau, tel qu'il est traditionnel dans la typographie me parait davantage relever du musée que de la vie courante. C'est plus un boulet qu'un acquis. Il est déjà souvent bien difficile de garder un(e?) espace avant les ;:!? et quand par malheur tout ca se retrouve dans une URL (titre de page html), on frise l'apoplexie :-)
jdd
C'est un point de vu. Je note d'ailleurs qu'il ne me semble pas spécifiquement contre l'espace fine. C'est un autre débat je pense, doit-on essayer de respecter au mieux les règles typographiques françaises ?
À priori, en me référant par exemple aux règles typographiques actuelles de Gnome ( http://traduc.org/gnomefr/Typographie ) on tend plus vers le oui (avec des exceptions, comme pour les apostrophes à la française).
Il y est d'ailleurs explicitement indiqué que les fines ne sont pas utilisées uniquement pour des raisons techniques (ce qui va donc dans mon sens puisque je pense avoir démontré que cette limite n'avait plus lieu d'être concernant Gnome).
Au passage, je précise tout de même que la situation que je souhaite (et donc souhaitable rigoureusement parlant) n'introduirait pas de complexité supplémentaire par rapport à maintenant. Il s'agira juste de taper « Alt Gr + v » à la place de « ctrl + maj + espace » (promis, on s'y fait vite ;-)).
Nicolas
On Tue, Aug 24, 2010 at 01:32:37PM +0200, Nicolas Delvaux wrote:
C'est un point de vu.
Ou de vue? ;)
Pour les TTY, tu veux dire dans Ctrl+Alt+F1? Là j'ai un (R) qui apparaît.
Sinon pour gnome-terminal, xterm, et konsole, j'ai bien une espace insécable (pas une espace classique, ni de losange, ni de vide) quand je tape AltGr+V - donc a priori pas de soucis (Debian Lenny). Dans quels cas as-tu un problème?
Le mardi 24 août 2010 à 14:14 +0200, Sylvain Beucler a écrit :
On Tue, Aug 24, 2010 at 01:32:37PM +0200, Nicolas Delvaux wrote:
C'est un point de vu.
Ou de vue? ;)
Oups ;)
Pour les TTY, tu veux dire dans Ctrl+Alt+F1?
Oui
Là j'ai un (R) qui apparaît.
Sinon pour gnome-terminal, xterm, et konsole, j'ai bien une espace insécable (pas une espace classique, ni de losange, ni de vide) quand je tape AltGr+V - donc a priori pas de soucis (Debian Lenny). Dans quels cas as-tu un problème?
Jette un œil sur mon rapport (je l'ai écrit pour ça) http://malaria.perso.sfr.fr/fines/fines.pdf C'est dans la partie II (Mode texte)
Et chez moi konsole ne marche pas non plus (comme toutes les appli Qt) (test plutôt avec le commande « echo 'Test !' », avec une espace fine bien sûr ;))
Bonjour Nicolas,
J'imagine de plus qu'un patch faisant grosso modo comprendre aux TTY que, au niveau de l'affichage, « espace fine insécable = espace insécable » serait assez simple à implémenter et règlerait notre problème (même si c'est faux, sémantiquement)
Le hic c'est que je ne sais pas contre quel logiciel rapporter ce bug : je ne sais pas quel programme « fournit » les TTY (ou du moins gère leurs rendus de textes).
Il s'agit ici du programme /bin/setfont et des fichiers qui se trouvent dans /usr/share/kbd/unimaps/*.uni, tous deux faisant partie du paquetage 'kbd'.
Pour faire comprendre à la console du noyau Linux (attention, je fais la distinction entre la "console" qui est l'affichage "mode texte" sans X11 et le "tty" qui est un mécanisme qui s'applique également à xterm, konsole, rxvt) il suffit de trois étapes:
1. Sauvegarder le mapping Unicode de la console: $ setfont -v -ou unimap et voir que ce fichier contient deux lignes 0x20 U+0020 0x20 U+00a0
2. Ajouter une ligne 0x20 U+202f à ce fichier, et le sauvegarder.
3. Appliquer ce fichier: $ setfont -v -u unimap
Et maintenant, essaye $ /usr/bin/printf '\u202Fx\n' et tu vois que c'est bon.
Donc, à ta place, j'écrirais au gérand de 'kbd' [1][2] en lui proposant de traiter U+202f de la même manière que U+00a0 dans tous les fichiers *.uni.
Je note que ceci serait consistent avec la fonction 'wcwidth' de la glibc: Ce programme ============================================================= #include <locale.h> #include <wctype.h> #include <wchar.h> #include <stdio.h> int main () { setlocale (LC_ALL, "de_DE.UTF-8"); printf ("wcwidth (0x00A0) = %d\n", wcwidth (0x00A0)); printf ("wcwidth (0x202F) = %d\n", wcwidth (0x202F)); return 0; } ============================================================= affiche: wcwidth (0x00A0) = 1 wcwidth (0x202F) = 1
Bruno
[1] https://lists.altlinux.org/mailman/listinfo/kbd [2] http://git.altlinux.org/people/legion/packages/kbd.git
Bonsoir,
J'imagine de plus qu'un patch faisant grosso modo comprendre aux TTY que, au niveau de l'affichage, « espace fine insécable = espace insécable » serait assez simple à implémenter et règlerait notre problème (même si c'est faux, sémantiquement)
Le hic c'est que je ne sais pas contre quel logiciel rapporter ce bug : je ne sais pas quel programme « fournit » les TTY (ou du moins gère leurs rendus de textes).
Il s'agit ici du programme /bin/setfont et des fichiers qui se trouvent dans /usr/share/kbd/unimaps/*.uni, tous deux faisant partie du paquetage 'kbd'.
Pour faire comprendre à la console du noyau Linux (attention, je fais la distinction entre la "console" qui est l'affichage "mode texte" sans X11 et le "tty" qui est un mécanisme qui s'applique également à xterm, konsole, rxvt) il suffit de trois étapes:
Sauvegarder le mapping Unicode de la console: $ setfont -v -ou unimap et voir que ce fichier contient deux lignes 0x20 U+0020 0x20 U+00a0
Ajouter une ligne 0x20 U+202f à ce fichier, et le sauvegarder.
Appliquer ce fichier: $ setfont -v -u unimap
Et maintenant, essaye $ /usr/bin/printf '\u202Fx\n' et tu vois que c'est bon.
Donc, à ta place, j'écrirais au gérand de 'kbd' [1][2] en lui proposant de traiter U+202f de la même manière que U+00a0 dans tous les fichiers *.uni.
Je note que ceci serait consistent avec la fonction 'wcwidth' de la glibc: Ce programme ============================================================= #include <locale.h> #include <wctype.h> #include <wchar.h> #include <stdio.h> int main () { setlocale (LC_ALL, "de_DE.UTF-8"); printf ("wcwidth (0x00A0) = %d\n", wcwidth (0x00A0)); printf ("wcwidth (0x202F) = %d\n", wcwidth (0x202F)); return 0; } ============================================================= affiche: wcwidth (0x00A0) = 1 wcwidth (0x202F) = 1
Bruno
[1] https://lists.altlinux.org/mailman/listinfo/kbd [2] http://git.altlinux.org/people/legion/packages/kbd.git
Merci beaucoup, c'est très intéressant ! Je remarque donc au passage que l'insécabilité n'est pas prise en compte dans les TTY.
Tes commandes fonctionnent également chez moi, je ne pensais pas que ça serait aussi simple.
Par contre j'ai comme un problème (qui n'en est peut-être pas un) : il n'y a aucun fichier .uni installé sur mon système. Je suis sous Ubuntu mais il semble qu'il en soit de même sous Debian. J'ai vérifié le paquet source de kbd et il contient effectivement les fichiers .uni, mais ceux-ci ne se retrouvent pas dans les paquets binaires.
Je n'ai pas bien compris la façon dont la chose a été packagée, mais admettons qu'une correction en amont règlera ici aussi le problème. (et comme dit précédemment, tes commandes fonctionnent)
Je n'ai pas trouvé de bug-tracker pour kbd, il faut vraiment les contacter directement sur leur liste de diffusion ? Tu as l'air de t'y connaitre mieux que moi techniquement, est-ce que ça te dérangerais de t'en occuper ? (sinon je m'en chargerai)
Merci encore !
Nicolas
ps : il ne manque plus qu'un connaisseur en Qt nous donne son avis sur les tenants du ou des bugs de rendu associés.
Le Tue, 24 Aug 2010 23:44:17 +0200, Nicolas Delvaux nicolas.delvaux@gmx.com a écrit :
Bonsoir,
bonsoir
J'imagine de plus qu'un patch faisant grosso modo comprendre aux TTY que, au niveau de l'affichage, « espace fine insécable = espace insécable » serait assez simple à implémenter et règlerait notre problème (même si c'est faux, sémantiquement)
Le hic c'est que je ne sais pas contre quel logiciel rapporter ce bug : je ne sais pas quel programme « fournit » les TTY (ou du moins gère leurs rendus de textes).
Il s'agit ici du programme /bin/setfont et des fichiers qui se trouvent dans /usr/share/kbd/unimaps/*.uni, tous deux faisant partie du paquetage 'kbd'.
Pour faire comprendre à la console du noyau Linux (attention, je fais la distinction entre la "console" qui est l'affichage "mode texte" sans X11 et le "tty" qui est un mécanisme qui s'applique également à xterm, konsole, rxvt) il suffit de trois étapes:
Sauvegarder le mapping Unicode de la console: $ setfont -v -ou unimap et voir que ce fichier contient deux lignes 0x20 U+0020 0x20 U+00a0
Ajouter une ligne 0x20 U+202f à ce fichier, et le sauvegarder.
Appliquer ce fichier: $ setfont -v -u unimap
Et maintenant, essaye $ /usr/bin/printf '\u202Fx\n' et tu vois que c'est bon.
Donc, à ta place, j'écrirais au gérand de 'kbd' [1][2] en lui proposant de traiter U+202f de la même manière que U+00a0 dans tous les fichiers *.uni.
Je note que ceci serait consistent avec la fonction 'wcwidth' de la glibc: Ce programme ============================================================= #include <locale.h> #include <wctype.h> #include <wchar.h> #include <stdio.h> int main () { setlocale (LC_ALL, "de_DE.UTF-8"); printf ("wcwidth (0x00A0) = %d\n", wcwidth (0x00A0)); printf ("wcwidth (0x202F) = %d\n", wcwidth (0x202F)); return 0; } ============================================================= affiche: wcwidth (0x00A0) = 1 wcwidth (0x202F) = 1
Bruno
[1] https://lists.altlinux.org/mailman/listinfo/kbd [2] http://git.altlinux.org/people/legion/packages/kbd.git
Merci beaucoup, c'est très intéressant !
+1
Je remarque donc au passage que l'insécabilité n'est pas prise en compte dans les TTY.
Tes commandes fonctionnent également chez moi, je ne pensais pas que ça serait aussi simple.
pas aussi simple pour moi, car il n'y a pas de setfont sous debian squeeze
il n'y a pas (plus) de paquet kbd, et console-tools ne contient pas de commande "setfont"
-- Package: console-tools .../ Description-fr: Utilitaires console et polices de Linux Ce paquet vous permet de configurer et de manipuler la console Linux (l'écran et le clavier), et de manipuler les fichiers console-font. . « console-tools » a été développé à partir de la version 0.94 du paquet standard « kbd », et intègre de nombreux correctifs et améliorations, incluant les nouvelles fonctionnalités de kbd jusqu'à la version 0.99.
Par contre j'ai comme un problème (qui n'en est peut-être pas un) : il n'y a aucun fichier .uni installé sur mon système. Je suis sous Ubuntu mais il semble qu'il en soit de même sous Debian.
moi j'en ai 4, dans /usr/share/consoletrans, et ils appartiennent au paquet console-data
mes 2 centimes...
J'ai vérifié le paquet source de kbd et il contient effectivement les fichiers .uni, mais ceux-ci ne se retrouvent pas dans les paquets binaires.
Je n'ai pas bien compris la façon dont la chose a été packagée, mais admettons qu'une correction en amont règlera ici aussi le problème. (et comme dit précédemment, tes commandes fonctionnent)
Je n'ai pas trouvé de bug-tracker pour kbd, il faut vraiment les contacter directement sur leur liste de diffusion ? Tu as l'air de t'y connaitre mieux que moi techniquement, est-ce que ça te dérangerais de t'en occuper ? (sinon je m'en chargerai)
Merci encore !
Nicolas
ps : il ne manque plus qu'un connaisseur en Qt nous donne son avis sur les tenants du ou des bugs de rendu associés.
Bonjour,
pas aussi simple pour moi, car il n'y a pas de setfont sous debian squeeze
il n'y a pas (plus) de paquet kbd, et console-tools ne contient pas de commande "setfont"
-- Package: console-tools .../ Description-fr: Utilitaires console et polices de Linux Ce paquet vous permet de configurer et de manipuler la console Linux (l'écran et le clavier), et de manipuler les fichiers console-font. . « console-tools » a été développé à partir de la version 0.94 du paquet standard « kbd », et intègre de nombreux correctifs et améliorations, incluant les nouvelles fonctionnalités de kbd jusqu'à la version 0.99.
Il s'agit en fait des paquets kbd et console-setup. J'ai vérifié et les 2 sont bien installés sur ma partition Debian Sid, comme sous Lucid (mais du coup je ne sais pas s'ils sont installés par défaut, je pense mais ça semble être en contradiction avec ce que tu constates...)
Par contre j'ai comme un problème (qui n'en est peut-être pas un) : il n'y a aucun fichier .uni installé sur mon système. Je suis sous Ubuntu mais il semble qu'il en soit de même sous Debian.
moi j'en ai 4, dans /usr/share/consoletrans, et ils appartiennent au paquet console-data
mes 2 centimes...
Effectivement, moi aussi.
Voici un extrait du README du paquet source de console-data (qui est un paquet propre à Debian) :
Please note that console-data will be re-merged with kbd in the next Debian release; [...] This release removes all conflicts with 'kbd' from console-data and makes console-data an optional package, which recommends 'kbd'. It still generates all the udebs for debian-installer, though; this will probably migrate to 'kbd'. With this release, you can now install 'kbd' and 'console-data', leaving out the obsolete 'console-tools'.
Voila qui est rassurant donc, et j'ai effectivement pu vérifier que les fichiers .uni de console-data sont bien les mêmes que ceux fournis dans les sources de kbd (les md5 sont identiques).
Problème résolu donc ? Il ne reste plus qu'à corriger le problème chez kbd je pense.
Nicolas
J'ai envoyé un mail sur la liste de kbd. Sachant que ça fait tout de même 4 mois que rien n'y a été posté, je ne suis pas sûr du résultat. Mais nous verrons bien.
En tout cas, parmi les 2 gros bugs qui (d'après mes tests) empêchent encore (techniquement) une partie des logiciels libres de passer à l'espace fine, il semble donc que l'un d'eux soit en bonne voie.
Reste donc Qt. Y a-t-il des adeptes de Qt et/ou des « KDEistes » dans l'assistance ? Ou dois-je aller les harceler sur leur propre liste de diffusion ?
Vu que je ne connais rien a Qt (hormis le fait qu'il ne supporte pas l'espace fine insécable ;-)), il serait je pense plus efficace que quelqu'un ayant au moins quelques bases s'en occupe. À défaut je m'en chargerais mais bon, ça m'embêterais un peu.
Nicolas
Pour info, en HTML/SGML, l'espace fine insécable s'obtient avec   et la fine sécable avec   Cf. http://typofute.com/l_espace_fine_insecable_dans_les_documents_html
Ça fonctionne Firefox/Chrome mais pas dans Opera (une espace normale est insérée). J'ai pas testé dans IE... j'ai eu la flemme de redémarrer en windows juste pour ça, et n'ai pas de VM win dispo.
Qqn peut-il vérifier ?
Frédéric
Le jeudi 26 août 2010 à 00:15 +0200, Frédéric Delanoy a écrit :
Pour info, en HTML/SGML, l'espace fine insécable s'obtient avec   et la fine sécable avec   Cf. http://typofute.com/l_espace_fine_insecable_dans_les_documents_html
Ça fonctionne Firefox/Chrome mais pas dans Opera (une espace normale est insérée). J'ai pas testé dans IE... j'ai eu la flemme de redémarrer en windows juste pour ça, et n'ai pas de VM win dispo.
Qqn peut-il vérifier ?
Il y a une partie « Rendu de pages web » dans mon compte rendu.
Pour rappel, c'est à cette adresse : http://malaria.perso.sfr.fr/fines/fines.pdf
2010/8/26 Nicolas Delvaux nicolas.delvaux@gmx.com:
Le jeudi 26 août 2010 à 00:15 +0200, Frédéric Delanoy a écrit :
Pour info, en HTML/SGML, l'espace fine insécable s'obtient avec   et la fine sécable avec   Cf. http://typofute.com/l_espace_fine_insecable_dans_les_documents_html
Ça fonctionne Firefox/Chrome mais pas dans Opera (une espace normale est insérée). J'ai pas testé dans IE... j'ai eu la flemme de redémarrer en windows juste pour ça, et n'ai pas de VM win dispo.
Qqn peut-il vérifier ?
Il y a une partie « Rendu de pages web » dans mon compte rendu.
Je sais, mais tu as ajouté une entrée de menu avec une espace insécable. J'ai testé une "bête" page HTML, sans modif quelconque dans le code de firefox.
Il serait intéressant de vérifier si ça marche avec les documents Docbooks convertis en HTML ou PDF.
Frédéric
Je sais, mais tu as ajouté une entrée de menu avec une espace insécable. J'ai testé une "bête" page HTML, sans modif quelconque dans le code de firefox.
Il serait intéressant de vérifier si ça marche avec les documents Docbooks convertis en HTML ou PDF.
Non non, j'ai bien testé une page HTML (sous gtk-webkit, KHTML, qt-webkit, Firefox et IE)
Tu dois confondre avec la partie sur Mozilla où j'ai effectivement modifié un menu (car pour moi la traduction de l'application en elle même et le rendu HTML sont deux choses bien distinctes).
Pour les docbooks, j'essaierai d'y jeter un œil demain (ah, on me souffle dans l'oreillette qu'on est déjà demain... disons tout à l'heure alors ;-))
Il serait intéressant de vérifier si ça marche avec les documents Docbooks convertis en HTML ou PDF.
Je ne m'étais jamais intéressé à docbook avant, donc j'ai pris le premier tutoriel venu où les fichiers xml et xsl étaient fournis : http://inf356.monoidal.net/docbook.html Du coup je ne sais pas si mon test est très représentatif, j'imagine que les résultats peuvent varier selon le moteur de conversion utilisé.
Enfin bref, il s'agit ici de « fop » (il me semble) et le résultat obtenu est correct pour une conversion XHTML (en fait l'espace fine est bien transcrite dans le fichier HTML, donc le rendu dépend du navigateur et du système d'exploitation, cf. mon compte rendu).
Par contre, la conversion vers PDF ne marche pas chez moi, ça me met un dièse à la place. Peut-être n'est-ce qu'une question de configuration ? J'imagine que c'est similaire à latex et qu'un bon rendu en français nécessite quelques réglages spécifiques (feuille xsl dédiée par exemple), non ?
Si quelqu'un avait la possibilité de re-tester sur un vrai docbook 100% français, ça pourrait être intéressant.
Nicolas
2010/8/26 Nicolas Delvaux nicolas.delvaux@gmx.com:
J'imagine que c'est similaire à latex et qu'un bon rendu en français nécessite quelques réglages spécifiques (feuille xsl dédiée par exemple), non ?
Pour autant que je me souvienne, le moteur de LaTeX (en tout cas avec babel) gère correctement les espaces entourant les signes de ponctuation double, et offre ~ et , pour les espaces insécables normales et fines respectivement (p.ex. dans les nombres, M. Durand, ...).
La conversion ps/PDF ne pose pas de problème, mais je n'ai pas d'expérience avec la conversion en HTML (avec katex2html, ou HEVEA). Peux-être quelqu'un pourra-t-il vérifier cela vite fait ?
Cf. http://www.tuteurs.ens.fr/logiciels/latex/astuces.html p.ex.
Frédéric
Le vendredi 27 août 2010 à 00:58 +0200, Frédéric Delanoy a écrit :
2010/8/26 Nicolas Delvaux nicolas.delvaux@gmx.com:
J'imagine que c'est similaire à latex et qu'un bon rendu en français nécessite quelques réglages spécifiques (feuille xsl dédiée par exemple), non ?
Pour autant que je me souvienne, le moteur de LaTeX (en tout cas avec babel) gère correctement les espaces entourant les signes de ponctuation double, et offre ~ et , pour les espaces insécables normales et fines respectivement (p.ex. dans les nombres, M. Durand, ...).
La conversion ps/PDF ne pose pas de problème, mais je n'ai pas d'expérience avec la conversion en HTML (avec katex2html, ou HEVEA). Peux-être quelqu'un pourra-t-il vérifier cela vite fait ?
Vu que mon compte rendu est écrit en LaTeX, j'ai pu tester très facilement.
En guise de remarque générale, je dirais que la conversion en HTML n'est vraiment pas au point : de nombreuses macro LaTeX ne sont pas rendues correctement et le résultat final n'est pas terrible (ça n'a rien à voir avec un rendu PDF).
En ce qui concerne l'espace fine, je n'ai pu tester qu'avec HEVEA (latex2html plante en ne reconnaissant pas certaines commandes). Dans le document HTML que j'obtiens, toutes les espaces fines insécables sont remplacées par des espaces insécables classiques.
C'est surement un comportement voulu. Mais pour obtenir un meilleur résultat il pourrait générer un fichier avec une astuce de ce genre (qui du coup fonctionne sur tous les navigateurs) : http://www.developpez.net/forums/d606257/php/langage/regex/gestion-espaces-f...
Enfin bon, ça ne me parait pas dramatique.
Nicolas
2010/8/26 Nicolas Delvaux nicolas.delvaux@gmx.com: En ce qui concerne l'espace fine, je n'ai pu tester qu'avec HEVEA (latex2html plante en ne reconnaissant pas certaines commandes). Dans le document HTML que j'obtiens, toutes les espaces fines insécables sont remplacées par des espaces insécables classiques.
C'est surement un comportement voulu. Mais pour obtenir un meilleur résultat il pourrait générer un fichier avec une astuce de ce genre (qui du coup fonctionne sur tous les navigateurs) : http://www.developpez.net/forums/d606257/php/langage/regex/gestion-espaces-f...
Enfin bon, ça ne me parait pas dramatique.
Ça me paraît quand même lourd d'utiliser des span / CSS pour les espaces fines insécables, alors que le Narrow No-Break Space ( ) est défini dans Unicode 3 (version de 1999). Mais c'est le plus compatible.
J'ai testé avec IE6 et ça ne marche pas là (carré blanc... étrange...). Par contre, IE7 affiche une espace normale, mais pas de carré blanc. Les navigateurs récents supportent ce caractère (à l'exception d'Opera; j'ai rapporté un bug). Chrome est légèrement buggé aussi (insécabilité du   mais le   fonctionner correctement); je vais rapporter un bug également.
Frédéric
Le vendredi 27 août 2010 à 16:03 +0200, Frédéric Delanoy a écrit :
2010/8/26 Nicolas Delvaux nicolas.delvaux@gmx.com: En ce qui concerne l'espace fine, je n'ai pu tester qu'avec HEVEA (latex2html plante en ne reconnaissant pas certaines commandes). Dans le document HTML que j'obtiens, toutes les espaces fines insécables sont remplacées par des espaces insécables classiques.
C'est surement un comportement voulu. Mais pour obtenir un meilleur résultat il pourrait générer un fichier avec une astuce de ce genre (qui du coup fonctionne sur tous les navigateurs) : http://www.developpez.net/forums/d606257/php/langage/regex/gestion-espaces-f...
Enfin bon, ça ne me parait pas dramatique.
Ça me paraît quand même lourd d'utiliser des span / CSS pour les espaces fines insécables, alors que le Narrow No-Break Space ( ) est défini dans Unicode 3 (version de 1999). Mais c'est le plus compatible.
On parle ici d'un code généré automatiquement, donc peut importe la lourdeur. ;-) Ça pourrait être une option lors de la transcription par exemple.
Après pour les pages faites « à la main » il faut effectivement êtres motivé (quoi que, avec un script qui remplacerait automatiquement toutes les fines par les span correspondants, ça doit rester à peu près supportable, même si ça fait toujours un plus de boulot que sans).
J'ai testé avec IE6 et ça ne marche pas là (carré blanc... étrange...). Par contre, IE7 affiche une espace normale, mais pas de carré blanc.
Sous quel système d'exploitation ? (Pour IE c'est plus l'OS qui compte que la version, par exemple IE 8 affiche la fine correctement sous Windows 7 mais affiche un carré blanc sous XP (à cause du moteur de rendu de textes qui est celui intégré à l'OS).
Les navigateurs récents supportent ce caractère (à l'exception d'Opera; j'ai rapporté un bug).
Opera n'utilise-t-il pas le moteur de rendu de textes de Qt ? Je n'en sais rien, mais si oui on en revient toujours au même bug... (toujours pas de connaisseurs dans l'assistance ?)
Chrome est légèrement buggé aussi (insécabilité du   mais le   fonctionner correctement); je vais rapporter un bug également.
Merci infiniment pour ton aide. Pourrais-tu donner les liens des bugs que tu as rapporté, histoire que je (et peut-être d'autres) puisse suivre leur évolution ?
Bonne journée,
Nicolas
2010/8/27 Nicolas Delvaux nicolas.delvaux@gmx.com:
Le vendredi 27 août 2010 à 16:03 +0200, Frédéric Delanoy a écrit :
Ça me paraît quand même lourd d'utiliser des span / CSS pour les espaces fines insécables, alors que le Narrow No-Break Space ( ) est défini dans Unicode 3 (version de 1999). Mais c'est le plus compatible.
On parle ici d'un code généré automatiquement, donc peut importe la lourdeur. ;-) Ça pourrait être une option lors de la transcription par exemple.
Après pour les pages faites « à la main » il faut effectivement êtres motivé (quoi que, avec un script qui remplacerait automatiquement toutes les fines par les span correspondants, ça doit rester à peu près supportable, même si ça fait toujours un plus de boulot que sans).
Mouais... rien qu'un petit script sed/ruby ne puisse changer facilement. Mais pourquoi réinventer la roue quand un caractère idoine existe ? Il est déjà pris en charge dans la plupart des navigateurs récents, et même l'écrasante majorité des utilisateurs windows utilisant IE ont une version > 6.
AMHA ce n'est qu'un "hack" qui n'a plus lieu d'être à l'heure actuelle.
J'ai testé avec IE6 et ça ne marche pas là (carré blanc... étrange...). Par contre, IE7 affiche une espace normale, mais pas de carré blanc.
Sous quel système d'exploitation ?
Euh en fait sous Wine, mais je ne suis pas sûr qu'il faille faire beaucoup/tant d'efforts pour supporter (dans tous les sens du terme...) IE 6
(Pour IE c'est plus l'OS qui compte que la version, par exemple IE 8 affiche la fine correctement sous Windows 7 mais affiche un carré blanc sous XP (à cause du moteur de rendu de textes qui est celui intégré à l'OS).
Oh. Je ne savais pas. C'est un XP complètement patché ?
Les navigateurs récents supportent ce caractère (à l'exception d'Opera; j'ai rapporté un bug).
Opera n'utilise-t-il pas le moteur de rendu de textes de Qt ?
Ils ont réimplémenté le moteur graphique en se passant de QT (moteur Vega) depuis les versions 10.5
Je n'en sais rien, mais si oui on en revient toujours au même bug... (toujours pas de connaisseurs dans l'assistance ?)
Chrome est légèrement buggé aussi (insécabilité du   mais le   fonctionner correctement); je vais rapporter un bug également.
Merci infiniment pour ton aide. Pourrais-tu donner les liens des bugs que tu as rapporté, histoire que je (et peut-être d'autres) puisse suivre leur évolution ?
Difficile pour Opera; ils n'offrent pas un accès public à leur base de données de bugs. Bref, on sait juste quand on l'a soumis, et quand ils l'ont corrigé dans le changelog. C'est le DSK-311629
Pour chrome, je ne l'ai pas encore fait (j'utilise SRWare Iron en fait); faudrait que je vérifie avec la dernière version de dev (mais le bug n'est pas très grave : insécabilité au lieu de sécabilité pour  )
Bonne journée,
Nicolas
À+
Frédéric
Le vendredi 27 août 2010 à 19:51 +0200, Frédéric Delanoy a écrit :
2010/8/27 Nicolas Delvaux nicolas.delvaux@gmx.com:
Le vendredi 27 août 2010 à 16:03 +0200, Frédéric Delanoy a écrit :
Ça me paraît quand même lourd d'utiliser des span / CSS pour les espaces fines insécables, alors que le Narrow No-Break Space ( ) est défini dans Unicode 3 (version de 1999). Mais c'est le plus compatible.
On parle ici d'un code généré automatiquement, donc peut importe la lourdeur. ;-) Ça pourrait être une option lors de la transcription par exemple.
Après pour les pages faites « à la main » il faut effectivement êtres motivé (quoi que, avec un script qui remplacerait automatiquement toutes les fines par les span correspondants, ça doit rester à peu près supportable, même si ça fait toujours un plus de boulot que sans).
Mouais... rien qu'un petit script sed/ruby ne puisse changer facilement. Mais pourquoi réinventer la roue quand un caractère idoine existe ? Il est déjà pris en charge dans la plupart des navigateurs récents, et même l'écrasante majorité des utilisateurs windows utilisant IE ont une version > 6.
AMHA ce n'est qu'un "hack" qui n'a plus lieu d'être à l'heure actuelle.
Malheureusement non donc. L'espace fine insécable n'est pas supportée pour ceux qui sont sous XP et qui utilisent IE (je ne sais pas ce qu'il en est sous Vista), dans tous les navigateurs basés sur Qt (Konqueror, Rekonq...), dans Opera et, selon des sources à confirmer, ça ne marche pas non plus dans Safari sous OS X.
Crois bien que cela me désole, mais il ne me semble pas réaliste aujourd'hui d'utiliser massivement l'espace fine (du moins le caractère idoine) sur Internet. Il faudrait au moins attendre que la part de marché de XP baisse significativement.
Note au passage que l'actuelle « incompatibilité » entre la fine et le web ne rentre pas en contradiction avec le projet de commencer à utiliser l'espace fine insécable dans les traductions de tous les logiciels libres, car l'écrasante majorité de nos traductions ne sont jamais interprétées pas des navigateurs web.
Il y a aussi des usages « internes ». Le premier exemple qui me vient ce sont les diapos qui défilent pendant l'installation de Ubuntu : ce sont des pages HTML rendues dans un widget webkit-gtk. Vu que le rendu de la fine ne pose pas de problème ici (comme dans tout ce qui est en GTK), on peut donc l'utiliser dans la traduction correspondante sans se poser de questions.
Bref, comme dit dans mon compte rendu, la situation n'est pas brillante mais est loin d'être bloquante pour autant. Et on peut tout de même être optimiste car ça évolue dans le bon sens.
J'ai testé avec IE6 et ça ne marche pas là (carré blanc... étrange...). Par contre, IE7 affiche une espace normale, mais pas de carré blanc.
Sous quel système d'exploitation ?
Euh en fait sous Wine, mais je ne suis pas sûr qu'il faille faire beaucoup/tant d'efforts pour supporter (dans tous les sens du terme...) IE 6
Il est vrai qu'a l'heure où des sites comme Gmail et Facebook ont (ou vont) abandonné son support, je pense qu'il n'y a pas de mal à ne plus s'en soucier.
Mais si ce n'était que IE 6...
(Pour IE c'est plus l'OS qui compte que la version, par exemple IE 8 affiche la fine correctement sous Windows 7 mais affiche un carré blanc sous XP (à cause du moteur de rendu de textes qui est celui intégré à l'OS).
Oh. Je ne savais pas. C'est un XP complètement patché ?
Oui.
(désolé d'en rajouter une couche mais c'est écrit, capture d'écran à l'appui, dans mon compte rendu depuis le premier jour :-p)
Opera n'utilise-t-il pas le moteur de rendu de textes de Qt ?
Ils ont réimplémenté le moteur graphique en se passant de QT (moteur Vega) depuis les versions 10.5
Ok.
Je n'en sais rien, mais si oui on en revient toujours au même bug... (toujours pas de connaisseurs dans l'assistance ?)
Chrome est légèrement buggé aussi (insécabilité du   mais le   fonctionner correctement); je vais rapporter un bug également.
Merci infiniment pour ton aide. Pourrais-tu donner les liens des bugs que tu as rapporté, histoire que je (et peut-être d'autres) puisse suivre leur évolution ?
Difficile pour Opera; ils n'offrent pas un accès public à leur base de données de bugs. Bref, on sait juste quand on l'a soumis, et quand ils l'ont corrigé dans le changelog. C'est le DSK-311629
Pour chrome, je ne l'ai pas encore fait (j'utilise SRWare Iron en fait); faudrait que je vérifie avec la dernière version de dev (mais le bug n'est pas très grave : insécabilité au lieu de sécabilité pour  )
Ok aussi ^^
Bonne soirée,
Nicolas
2010/8/27 Nicolas Delvaux nicolas.delvaux@gmx.com:
Le vendredi 27 août 2010 à 19:51 +0200, Frédéric Delanoy a écrit :
AMHA ce n'est qu'un "hack" qui n'a plus lieu d'être à l'heure actuelle.
Malheureusement non donc. L'espace fine insécable n'est pas supportée pour ceux qui sont sous XP et qui utilisent IE (je ne sais pas ce qu'il en est sous Vista), dans tous les navigateurs basés sur Qt (Konqueror, Rekonq...), dans Opera et, selon des sources à confirmer, ça ne marche pas non plus dans Safari sous OS X.
Crois bien que cela me désole, mais il ne me semble pas réaliste aujourd'hui d'utiliser massivement l'espace fine (du moins le caractère idoine) sur Internet. Il faudrait au moins attendre que la part de marché de XP baisse significativement.
OK. Dans ce cas le semble un pis-aller acceptable.
Note au passage que l'actuelle « incompatibilité » entre la fine et le web ne rentre pas en contradiction avec le projet de commencer à utiliser l'espace fine insécable dans les traductions de tous les logiciels libres, car l'écrasante majorité de nos traductions ne sont jamais interprétées pas des navigateurs web.
Pas certain, même les pages man ou info vont probablement être converties en HTML à un moment ou un autre ; dans ce cas il fau(drai)t tout de même vérifier la compatibilité des convertisseurs X -> HTML avant toute utilisation massive (et probablement documenter de façon proéminente la saisie de ces caractères/compatibilité)
Il y a aussi des usages « internes ». Le premier exemple qui me vient ce sont les diapos qui défilent pendant l'installation de Ubuntu : ce sont des pages HTML rendues dans un widget webkit-gtk. Vu que le rendu de la fine ne pose pas de problème ici (comme dans tout ce qui est en GTK), on peut donc l'utiliser dans la traduction correspondante sans se poser de questions.
OK
Bref, comme dit dans mon compte rendu, la situation n'est pas brillante mais est loin d'être bloquante pour autant. Et on peut tout de même être optimiste car ça évolue dans le bon sens.
Tu l'as dit, bouffi !
Frédéric
Note au passage que l'actuelle « incompatibilité » entre la fine et le web ne rentre pas en contradiction avec le projet de commencer à utiliser l'espace fine insécable dans les traductions de tous les logiciels libres, car l'écrasante majorité de nos traductions ne sont jamais interprétées pas des navigateurs web.
Pas certain, même les pages man ou info vont probablement être converties en HTML à un moment ou un autre ; dans ce cas il fau(drai)t tout de même vérifier la compatibilité des convertisseurs X -> HTML avant toute utilisation massive (et probablement documenter de façon proéminente la saisie de ces caractères/compatibilité)
C'est exactement ça, si problème il y a ou que des contournements doivent être mis en place, c'est au niveau des convertisseurs. Les traducteurs devraient pouvoir utiliser des espaces fines insécables partout sans avoir à se poser de questions. Si ça devient trop compliqué, les équipes de traductions seront naturellement réticentes pour l'adopter (enfin j'imagine que des exceptions pour un ou deux programmes restes envisageables, mais il faut que ça reste minime et que ça soit bien documenté).
Il faudrait donc faire une liste des convertisseurs X → HTML les plus utilisés et les tester. Il faudrait ensuite militer auprès des développeurs concernés pour soit : - remplacer automatiquement les fines par des AMHA solution la plus simple techniquement mais sémantiquement incorrecte, et puis à quoi bon, par exemple, mettre des fines dans les pages de man si elles ne sont ni affichées dans les terminaux (police à chasse fixe) ni dans les versions HTML ? Enfin, ça répond tout de même à la prérogative « ne pas se poser de questions ».
- utiliser des contournements comme nous l'avons vu précédemment. En soit cette solution ne me semble pas plus compliquée que précédemment, il s'agirait juste par exemple de remplacer automatiquement les fines par des « <span style="font-size: 50%;"> </span> » (pas besoin de CSS comme ça). Le seul inconvénient ici est que le code généré est plus lourd. À voir si c'est vraiment bloquant (modifie-t-on souvent manuellement les fichiers HTML générés ?)
J'ai mis à jour ma page HTML de test (cf. http://malaria.perso.sfr.fr/fines/fines.html ), il est maintenant possible de vérifier facilement que la version « simulée » de l'espace fine fonctionne dans tous les cas ou le caractère idoine ne fonctionne pas. (si quelqu'un est motivé pour refaire les tests de mon compte rendu avec cette nouvelle page, je serais ravi de le mettre à jour :D)
Bref, comme dit dans mon compte rendu, la situation n'est pas brillante mais est loin d'être bloquante pour autant. Et on peut tout de même être optimiste car ça évolue dans le bon sens.
Tu l'as dit, bouffi !
Oui, et le grand avantage de HTML c'est qu'il nous offre des solutions de contournement, contrairement aux bibliothèques graphiques (qui à dit Qt ?)
Bonne journée, Nicolas
2010/8/29 Nicolas Delvaux nicolas.delvaux@gmx.com:
C'est exactement ça, si problème il y a ou que des contournements doivent être mis en place, c'est au niveau des convertisseurs. Les traducteurs devraient pouvoir utiliser des espaces fines insécables partout sans avoir à se poser de questions. Si ça devient trop compliqué, les équipes de traductions seront naturellement réticentes pour l'adopter (enfin j'imagine que des exceptions pour un ou deux programmes restes envisageables, mais il faut que ça reste minime et que ça soit bien documenté).
Il faudrait donc faire une liste des convertisseurs X → HTML les plus utilisés et les tester.
Si besoin est, je peux me charger d'écrire un script convertisseur HTML -> HTML vite fait (en ruby p.ex.) pour la conversion - des documents dont l'original est en HTML - pour les résultats de convertisseurs "foireux" et le rendre disponible, p.ex. sur traduc pour que les traducteurs l'utilisent sur leur bécane mais ça risque d'être un peu lourd. Ou bien peut-être l'intégrer sur traduc.org avec une form + CGI p.ex., ou éventuellement utiliser 2 boîtes de texte et un bouton pour convertir (avec du javascript p.ex.)... les idées sont les bienvenues (mod_ruby?)
Mais la correction "à la base" est de toute façon préférable
Il faudrait ensuite militer auprès des développeurs concernés
Ça risque d'être compliqué : je vois mal (tous) les développeurs gérer la typographie française en particulier; sinon, ils devraient le faire pour d'autres langues utilisant d'autres conventions... (rien qu'en français, les conventions typographiques en usage en France et Québec p.ex. peuvent être différentes).
pour soit :
- remplacer automatiquement les fines par des
AMHA solution la plus simple techniquement mais sémantiquement incorrecte, et puis à quoi bon, par exemple, mettre des fines dans les pages de man si elles ne sont ni affichées dans les terminaux (police à chasse fixe) ni dans les versions HTML ? Enfin, ça répond tout de même à la prérogative « ne pas se poser de questions ».
Parce que les pages de manuel ne peuvent être converties en HTML ? Mais c'est moins primordial, je te l'accorde bien volontiers.
- utiliser des contournements comme nous l'avons vu précédemment.
En soit cette solution ne me semble pas plus compliquée que précédemment, il s'agirait juste par exemple de remplacer automatiquement les fines par des « <span style="font-size: 50%;"> </span> » (pas besoin de CSS comme ça).
Euh...le span *style*, c'est pas du CSS ? En tous cas, c'est probablement la seule solution viable dans l'immédiat, même si la plus lourde...
Le seul inconvénient ici est que le code généré est plus lourd. À voir si c'est vraiment bloquant (modifie-t-on souvent manuellement les fichiers HTML générés ?) [...] Oui, et le grand avantage de HTML c'est qu'il nous offre des solutions de contournement, contrairement aux bibliothèques graphiques (qui à dit Qt ?)
Nicolas
Dans l'immédiat, je pense qu'il faudrait - identifier les différents types de documents de traduc à traiter/examiner (texte pur, man, po?, docbook, fichiers "info", latex?) utilisés par Traduc - identifier les convertisseurs -> HTML/PDF principaux et leur comportement (ex: man2html, latex2html, ...)
En parallèle, vérifier que les convertisseurs fonctionnent (ou pas), et rapporter d'éventuels bugs.
Les anciens documents déjà traduits ne devraient être "fine"-ifiés que lors d'une mise à jour AMA.
Frédéric
Le dimanche 29 août 2010 à 18:09 +0200, Frédéric Delanoy a écrit :
2010/8/29 Nicolas Delvaux nicolas.delvaux@gmx.com:
C'est exactement ça, si problème il y a ou que des contournements doivent être mis en place, c'est au niveau des convertisseurs. Les traducteurs devraient pouvoir utiliser des espaces fines insécables partout sans avoir à se poser de questions. Si ça devient trop compliqué, les équipes de traductions seront naturellement réticentes pour l'adopter (enfin j'imagine que des exceptions pour un ou deux programmes restes envisageables, mais il faut que ça reste minime et que ça soit bien documenté).
Il faudrait donc faire une liste des convertisseurs X → HTML les plus utilisés et les tester.
Si besoin est, je peux me charger d'écrire un script convertisseur HTML -> HTML vite fait (en ruby p.ex.) pour la conversion
- des documents dont l'original est en HTML
- pour les résultats de convertisseurs "foireux"
et le rendre disponible, p.ex. sur traduc pour que les traducteurs l'utilisent sur leur bécane mais ça risque d'être un peu lourd. Ou bien peut-être l'intégrer sur traduc.org avec une form + CGI p.ex., ou éventuellement utiliser 2 boîtes de texte et un bouton pour convertir (avec du javascript p.ex.)... les idées sont les bienvenues (mod_ruby?)
Mais la correction "à la base" est de toute façon préférable
Effectivement tout ce que tu proposes pourrait être utile pour du dépannage en cas de problème, mais ça va être dur de s'en contenter. À moins que tout le monde soit super motivé pour adopter la fine (et je sais qu'il y a des récalcitrants), il faut vraiment viser l'embêtement zéro pour les traducteurs.
Et sinon, concernant tes idées de conversions HTML → HTML ou HTML "foireux" → HTML, pas la peine de trop en faire non plus. Tu peux faire quelque chose de simple et ergonomique si tu veux, mais n'oublie pas que dans la plupart des cas un simple coup de "chercher/remplacer tout" dans un éditeur de texte lambda suffira amplement. ;-)
Il faudrait ensuite militer auprès des développeurs concernés
Ça risque d'être compliqué : je vois mal (tous) les développeurs gérer la typographie française en particulier; sinon, ils devraient le faire pour d'autres langues utilisant d'autres conventions... (rien qu'en français, les conventions typographiques en usage en France et Québec p.ex. peuvent être différentes).
En l'occurrence il ne s'agit pas de gérer une règle typographique mais plutôt d'implémenter un contournement pour qu'un caractère Unicode soit affiché correctement sur l'ensemble des navigateurs de la planète (à peu de chose près ^^)
pour soit :
- remplacer automatiquement les fines par des
AMHA solution la plus simple techniquement mais sémantiquement incorrecte, et puis à quoi bon, par exemple, mettre des fines dans les pages de man si elles ne sont ni affichées dans les terminaux (police à chasse fixe) ni dans les versions HTML ? Enfin, ça répond tout de même à la prérogative « ne pas se poser de questions ».
Parce que les pages de manuel ne peuvent être converties en HTML ? Mais c'est moins primordial, je te l'accorde bien volontiers.
Et man2html ? (à moins que je n'ai pas compris)
- utiliser des contournements comme nous l'avons vu précédemment.
En soit cette solution ne me semble pas plus compliquée que précédemment, il s'agirait juste par exemple de remplacer automatiquement les fines par des « <span style="font-size: 50%;"> </span> » (pas besoin de CSS comme ça).
Euh...le span *style*, c'est pas du CSS ?
Si, bien sûr. Ce que je voulais dire c'est qu'ici le convertisseur n'a pas besoin de générer un *fichier* CSS uniquement pour la fine, c'est vraiment une simple substitution d'un caractère par une chaine ;-)
En tous cas, c'est probablement la seule solution viable dans l'immédiat, même si la plus lourde...
Le seul inconvénient ici est que le code généré est plus lourd. À voir si c'est vraiment bloquant (modifie-t-on souvent manuellement les fichiers HTML générés ?) [...] Oui, et le grand avantage de HTML c'est qu'il nous offre des solutions de contournement, contrairement aux bibliothèques graphiques (qui à dit Qt ?)
Nicolas
Dans l'immédiat, je pense qu'il faudrait
- identifier les différents types de documents de traduc à
traiter/examiner (texte pur, man, po?, docbook, fichiers "info", latex?) utilisés par Traduc
- identifier les convertisseurs -> HTML/PDF principaux et leur
comportement (ex: man2html, latex2html, ...)
À mon avis il faudrait déjà identifier les convertisseurs qui sont *vraiment* utilisés et surtout ceux qui sont utilisés « automatiquement » (dans des scripts pour mise en ligne automatique...). Par exemple un site comme celui-ci ( http://www.delafond.org/traducmanfr/index.php ) est fondé sur man2html. Vis à vis de l'espace fine insécable man2html devrait donc être vérifié et, si besoin, corrigé en priorité.
À contrario, il est à mon avis très rare de convertir de LaTeX vers HTML. De plus, d'après mon expérience, le résultat obtenu est tellement passable que l'on doit de toute façon re-modifier manuellement le fichier obtenu (on peut donc en profiter pour corriger les espaces fines au passage). Il est du coup, je pense, tout à fait acceptable que latex2html et consorts soient en bas de liste (voir qu'on ne s'en préoccupe pas pour le moment).
Bref, c'est une sorte d'appel à témoignage : quels convertisseurs X → HTML utilisez vous ? Devez vous systématiquement modifier le code généré ?
En parallèle, vérifier que les convertisseurs fonctionnent (ou pas), et rapporter d'éventuels bugs. Les anciens documents déjà traduits ne devraient être "fine"-ifiés que lors d'une mise à jour AMA.
Bien entendu. (sauf si des personnes sont suffisamment motivées pour "fine"-ifier à la chaine ;-))
Nicolas
Salut à tous,
devant l'enthousiasme général, je me suis résolu à rapporter le bug contre Qt moi même.
http://bugreports.qt.nokia.com/browse/QTBUG-13280
J'ai jeté un coup d'œil au code source de Qt et... je n'ai rien compris ^^ Encore une fois, si un connaisseur passe dans le coin son aide est la bienvenue.
Nicolas
Le lundi 30 août 2010 14:35:40, Nicolas Delvaux a écrit :
Salut à tous,
devant l'enthousiasme général, je me suis résolu à rapporter le bug contre Qt moi même.
Il y avait déjà un rapport de bug sur ce sujet :
http://bugreports.qt.nokia.com/browse/QTBUG-1201
Le lundi 30 août 2010 à 15:43 +0200, Bruno Patri a écrit :
Le lundi 30 août 2010 14:35:40, Nicolas Delvaux a écrit :
Salut à tous,
devant l'enthousiasme général, je me suis résolu à rapporter le bug contre Qt moi même.
Il y avait déjà un rapport de bug sur ce sujet :
Oui, mais il a été fermé pour une raison indéterminée. Vu que je ne pouvais pas le ré-ouvrir et qu'il y avait un bouton « clone this issue », j'en ai profité.
Le lundi 30 août 2010 17:59:14, Nicolas Delvaux a écrit :
Le lundi 30 août 2010 à 15:43 +0200, Bruno Patri a écrit :
Le lundi 30 août 2010 14:35:40, Nicolas Delvaux a écrit :
Salut à tous,
devant l'enthousiasme général, je me suis résolu à rapporter le bug contre Qt moi même.
Il y avait déjà un rapport de bug sur ce sujet :
Oui, mais il a été fermé pour une raison indéterminée. Vu que je ne pouvais pas le ré-ouvrir et qu'il y avait un bouton « clone this issue », j'en ai profité.
Ok la résolution de ce bug m'intéresse aussi car il est impossible d'utiliser l'espace fine insécable (U+202F) dans les applications KDE, y compris dans Lokalize qui l'outil utilisé par les traducteurs de KDE.
Le bug avait été fermé avec "out of scope". Je ne sais pas s'il faut comprendre hors de propos ou hors de portée... ;)
Le lundi 30 août 2010 à 18:06 +0200, Bruno Patri a écrit :
Le lundi 30 août 2010 17:59:14, Nicolas Delvaux a écrit :
Le lundi 30 août 2010 à 15:43 +0200, Bruno Patri a écrit :
Le lundi 30 août 2010 14:35:40, Nicolas Delvaux a écrit :
Salut à tous,
devant l'enthousiasme général, je me suis résolu à rapporter le bug contre Qt moi même.
Il y avait déjà un rapport de bug sur ce sujet :
Oui, mais il a été fermé pour une raison indéterminée. Vu que je ne pouvais pas le ré-ouvrir et qu'il y avait un bouton « clone this issue », j'en ai profité.
Ok la résolution de ce bug m'intéresse aussi car il est impossible d'utiliser l'espace fine insécable (U+202F) dans les applications KDE, y compris dans Lokalize qui l'outil utilisé par les traducteurs de KDE.
Le bug avait été fermé avec "out of scope". Je ne sais pas s'il faut comprendre hors de propos ou hors de portée... ;)
J'ai également oublié de préciser que tout le monde peut « voter » pour ce bug : à priori, plus il y aura de votes, plus le bug aura de chances d'attirer l'attention des développeurs. ;-) (il faut s'inscrire et cliquer sur le lien correspondant sur la page du bug)
À moins que l'un de nous soit capable de produire un patch, c'est la meilleure chose à faire je pense.
On Mon, Aug 30, 2010 at 14:35, Nicolas Delvaux nicolas.delvaux@gmx.com wrote:
Salut à tous,
devant l'enthousiasme général, je me suis résolu à rapporter le bug contre Qt moi même.
Des nouvelles sur ce bug ? Il semble ne pas avoir été modifié depuis plus d'un an. Peux-tu vérifier s'il subsiste encore ?
Frédéric
On Wednesday 14 March 2012, Frédéric Delanoy wrote:
On Mon, Aug 30, 2010 at 14:35, Nicolas Delvaux nicolas.delvaux@gmx.com
wrote:
Salut à tous,
devant l'enthousiasme général, je me suis résolu à rapporter le bug contre Qt moi même.
Des nouvelles sur ce bug ? Il semble ne pas avoir été modifié depuis plus d'un an. Peux-tu vérifier s'il subsiste encore ?
Il a été assigné à Eskil Abrahamsen Blomfeldt le 27 février 2012. Encore deux ou trois ans et ça devrait être corrigé :-).
Pour la défense de Qt, seulement cinq personnes ont voté pour ce bug. Les développeurs ont raison de ne pas lui accorder une priorité supérieure à « insignifiant ».
Frédéric
Bonjour,
Des nouvelles sur ce bug ? Il semble ne pas avoir été modifié depuis plus d'un an. Peux-tu vérifier s'il subsiste encore ?
Oui, ce bug est toujours présent. J'avais regardé le code source à l'époque, mais je m'étais rendu compte que la correction n'était pas triviale.
On aurait donc besoin de quelqu'un qui s'y connaît...
-
Bruno Haible -
Bruno Patri -
Frédéric Delanoy -
Frédéric Marchal -
jdd -
Nicolas Delvaux -
Nicolas Delvaux -
Odile Bénassy -
Sylvain Beucler