Espaces fines insécables entre les guillemets

Fragment of a discussion from User talk:Verdy p
Jump to navigation Jump to search

Pas que là. Je sais de quoi je parle ayant justement travaillé avec à peu près tous les professionnels de l'édition en France (aussi au Canada), ils demandaient tous la même chose ; y compris avec les guillemets. La référence que tu donnes de l'OQLF est antérieure à l'encodage de la fine en Unicode, mais l'éditique a la fine utilisée depuis longtemps, représentée en SGML, et même avant l'HTML et le web et que finalement elle soit ajoutée à l'Unicode (quand un autre usage a été ajouté aussi pour les langues asiatiques, mais le comité Unicode ne voulait pas en entendre parler avant, jugeant que c'était inutile pour l'éditique qui utilisait SGML ou les langages et feuille de style pour la mise en forme, pour marquer les caractères "insécables", et donc en utilisant la fine sécable déjà codée. L'Unicode s'appuyait en fait sur l'absence d'usage dans les textes bruts (sans mise en forme), qui ont malheureusement hérité des mauvaises pratiques de l'ASCII et des anciens jeux de caractères. Unicode était plus timide à l'époque et avait un certain conservatisme, même poru des prtaiques qui n'étaient nécessaires que par les limitations des anciens systèmes dactylographiques, très largement développés pour les langues européennes. L'Unicode a eu de nombreuses demandes pendant des années pour l'ajout de NNBSP, et encore aujourd'hui ce caractère est mal connu (et même Microsoft dans Windows le "cache" dans son outil "Charmap" où il n'est accessible dans aucune catégorie, et n'apparait que si on choisit une police qui le mappe directement (rare et en fait inutile), et choisissant d'afficher "tous les caractères" en mode Unicode, et il faut le chercher alors à sa position U+202F. L'outil "Charmap" a de nombreux bogues de classification jamais corrigés depuis longtemps malgré tous les signalements. Avec ça il n'a pas facilité la vie de ceux qui voulaient l'utiliser. Il aura fallu que ce soient les moteurs de rendu qui le prennent en charge (puisqu'il a été informellement décidé qu'il était vain d'attendre qu'il soit "mappé" dans les polices alors que le comportement attendu était pourtant bien documenté. Les pratiques de l'éditique professionnelle n'ont jamais changé. Et même l'imprimerie nationale (avec qui on travaillait) nous demandait explicitement de traiter les NNBSP pour la mise en page et même de l'afficher explicitement sous forme balisée dans les outils de saisie: on utilisant une balise "[FINE]" entre crochets et en gras et rouge, traitée comme un seul caractère à la saisie, et ce "caractère" était saisi avec la simple touche [F2] du clavier PC. Et on peut facilement s'en convaincre: il suffit de regarder les rendus PDF générés par les textes publiés par l'Inprimerie nationale, et dans le JORF: les guillemets ont bien une fine à l'intérieur, et non une espace insécable (c'est encore plus visible avec la justification du texte puisque la fine n'est PAS justifiée et conserve sa taille, mais l'espace insécable l'est et peut s'élargir comme l'espace normale!)

Verdy p (talk)18:07, 14 September 2019

Personnellement, je m’en moque que l’espace soit fine ou non.

Par contre je ne trouve pas normal que le changement soit fait de manière massive alors qu’il n’y a pas consensus.

Et ça me fatigue de devoir relire des tas de modifications juste pour une espace qui perd un quart de pixel de large. Faire le changement au passage, quand il y a un autre changement à faire, d’accord. Mais ne faire que ce changement là, c’est faire perdre du temps en relecture à tous les traducteurs de Translatewiki.net

Pols12 (talk)00:47, 10 October 2019

Faire perdre du temps ? Tu sembles oublier qu'on a beaucoup de retard sur les relectures. Le plus gros du temps c'est moi qui le passe à faire remonter les statistiques car on a des tonnes de fautes oubliées. Maintenant cela se fait sur l'interface de relecture elle-même. S'il y a des problèmes d'interprétation c'est que la doc est incomplète sur certains messages. De plus ces messages sont eux-mêmes parfois changés dans la version anglaise et on les voit de façon isolée hors contexte qui n'est pas précisé. Fatalement si on modifie de façon synchrone cela va réapparaître à l'interface des rares qui suivent, ce n'est pas pour "tous" les traducteurs. J'ai vu des arguments assez suspects comme le fait que NNBSP ne serait pas pris en charge sur MacOS et iOS, alors que c'est dans les docs même de MacOS et iOS depuis des années. Apple a commis un bogue sur certaines versions anciennes de MacOS lors d'une mise à jour malheureuse quand il a modifié simultanément la prise en charge intrinsèque des espaces dans son moteur et supprimé les mappings de ses polices : c'était cohérent pour les nouvelles versions de MacOS (et n'a pas fait disparaître ces espaces), mais le problème est arivé sur les anciennes versions de MacOS et iOS quand le moteur n'a pas été modifié mais de nouvelles versions des polices sans les mappings ont été chargées : ces polices n'auraient pas du avoir ces mappings supprimés. Cela a été corrigé et ne concerne que les polices Apple boguées qui ont été corrigées à nouveau pour restaurer ces mappings afiun de restaurer la compatibilité. Et cela n'a jamais concerné les autres polices non système. C'est bien une anomalie temporaire avec les anciennes versions (qui étaient correctes à l'origine) mais il n'y a pas eru de changemetn de recommandations (car les NNBSP sont restées nécessaires notamment pour les fines insécables des séparateurs de groupes de chiffres dans les nombres qui avaient disparu; Apple l'a corrigé mais certains rares utilisateurs ont remis des versions incorrectes de ces polices Apple, en fait une seule police était concernée par l'anomalie).On ne peut pas se baser sur ces anomalies transitoires de certains OS et les manipulations hasardeuses des utilisateurs sur leur appareil. Les fines sont standards en faire partout des espaces normales est incorrect et non conforme pour tous les autres utilisateurs qui sont l'immense majorité, y compris les utilisateurs de MacOS et iOS d'appareils assez récents (concernant iOS, les appareils sont nécessazirement anciens et leur batterie à bout de course, il reste les vieilles versions de MacOS où il n'y a pas de raison de ne pas installer les polices corrigées (pas de problème de place). Alors c'est un problème pour 0,000001% des utilisateurs, la très grande majorité voit ce qui est attendu et décrit dans les standards, décrits dans les docs d'Apple, documentés dans les forums Apple, et cohérent avec ce qui est présent dans les bibliothèques communes (CLDR par exemple) utilisées dans des tas de logiciels (y compris d'Apple). Enfin quant à dire que "j'ignore" les commentaires, ce n'est pas vrai mais les commentaire ne sont pas là où il faut quand on doit travailler sur des centaines de message dans l'interface de traduction car on ne les voit pas du tout (on ne voit que les commentaires de dans la page de doc "/qqq". Cela peut aboutir à quelques lignes avec désaccord mais ce n'est rien à côté des centaines de lignes sur lesquelles il y a des corrections tout à fait appropriées. Les désaccords viennent de l'absence de contexte (et de défaut de documentation).

Verdy p (talk)13:59, 2 December 2019

Non, tout est à jour et c’est la police par défaut qui est utilisée (qui ne peut pas être changée sur iOS de toute façon).

Safari est le deuxième navigateur en termes de parts de marché, ça ne concerne donc pas que « 0,000001% des utilisateurs ».

Merci de cesser les arguments fallacieux.

Thibaut (talk)14:26, 2 December 2019

Il suffit pourtant de regarder les nombreux forums de support pour Apple, c'est un bogue connu et admis par Apple et décrit aussi comme tel dans les discussions du standard Unicode. Tout marchait bien avant MacOS 8, corrigé ensuite avec des notes d'Apple. Et sinon le bogue concerne certaines versions d'iOS anciennes aussi. C'est Apple qui s'est planté et ne formate plus les nombres correctement à cause de ça. NNBSP est là depuis longtemps et s'il est invisible sur certains appareils c'est une minorité pas à jour avec les correctifs mais ça ne rend rien d'illisible et il est même préférable de ne rien voir que de voir une espace trop grande. Quant au fait de ne pas pouvoir changer de police c'est faux dans un navigateur même sur mobile.

Sinon encore une fois tu choisis le ton agressif avec un terme comme "fallacieux", plein de mauvaises intentions.

Verdy p (talk)15:44, 2 December 2019

> NBSP (U+00A0) n'est plus recommandé QUE comme repli au cas ou NNBSP (U+202F) ne peut pas être utilisé pour des raisons techniques

> c'est un bogue connu et admis par Apple

On est donc bien dans le cas des limitations techniques (que ce soit une limite inhérente à une architecture, un navigateur ou une mauvaise configuration par défaut ne change pas grand chose). Et les super-logiciels dont tu parles remplaceront automatiquement ces espaces par des espaces fines^^.

Trial (talk)20:58, 8 December 2019