Espaces fines

Si j’ai bien suivi la discussion…

Est-ce que NNBSP pose un problème d’accessibilité ?

La discussion semble avoir montré que si NNBSP est parfois invisible, c’est un choix d’Apple et non un bogue. Donc on n’a pas à changer de caractère pour être sûr qu’il s’affiche comme on le souhaite.

(Sinon, c’est comme si on imposait l’écriture en noir sur blanc, même pour ceux qui utilisent un navigateur qui affiche les textes en blanc sur noir.)

Est-ce que NNBSP est idéalement souhaitable ?

J’en suis resté aux sources données par Thibaut120094 : pour !, ? et ; il faut une NNBSP, pour les « », il faut des NBSP.

Dans un monde idéal où tous les navigateurs gèrent correctement l'espace fine insécable, il faut une NNBSP pour : aussi.

Après quelques tests, Safari semble traiter l'espace fine insécable comme une espace insécable de largeur zéro (U+FEFF) comme il le faisait il y a quatre ans pour l'espace fine normale et ça a été corrigé, c'est un bug, pas un choix.

AJOUT : Avec d'autres polices, comme la police libre DejaVu Sans Mono, le navigateur affiche des "tofu" ou "caractères de remplacement ou de substitution", ce qui prouve bien que c'est un bug.

AJOUT 2 : Voir aussi bugs.webkit.org : [1][2][3] et BugZilla.

Je n'ai pas la même lecture de ton ajout : ça veut dire que la police DejaVu n'a pas défini l'espace fin insécable, ni plus ni moins et la politique usuelle quand on essaye d'afficher un caractère absent de la police c'est d'afficher le caractère de remplacement. Donc pas un bogue, juste une police à ne pas utiliser si on veut afficher des espaces fines insécables. Ce que tu dis fait penser à ce que des polices définiraient l'espace fine comme un vide. Ce qui fait que beaucoup de polices sur Safari sont incapables de représenter les espaces fines. Et ces mêmes polices sur cette même machine affichent correctement des espaces fines en dehors de Safari ?

Le caractère U+202F (NARROW NO-BREAK SPACE) est bien défini dans DejaVu Mono Sans.

Toutes ces polices fonctionnent correctement sur macOS en dehors de Safari.

La page de test est disponible ici.

Je ne vois pas bien comment les programmeurs de Safari ont géré leur coup pour changer un caractère précis d’une police… Mais OK pour considérer ça comme un bogue jusqu’à qu’une source vienne confirmer que ce comportement est intentionnel (ou que le bogue soit corrigé chez 90 % des utilisateurs).

Donc, je crois qu’on est tous d’accord (sauf peut-être Verdy_p ?) pour ne plus utiliser NNBSP tant qu’il ne sera pas géré (ou assumé comme masqué intentionnellement) par Safari ?

Que Verdy_p soit d'accord ou pas puisque la règle locale est d'utiliser  , il faut utiliser  .

Sinon il faut commencer par changer les règles locales puisque je n'ai vu personne s'opposer au message d'Eichel. Hormis Verdy_p je veux dire^^ mais même dans ce cas puisque la règle WP s'applique à la partie WP pour des raisons de cohérence il est bon que les choix soient compatibles.

Je n'ai pas connaissance de règles locales exigeant NNSP (encore une fois je ne dis pas si c'est bien dans le cas idéal - oui sans doute - ou pas, je réponds à la question posée : doit-on utiliser actuellement les espaces insécables fines ou pas et ma réponse actuellement est non).

En effet, j’en avais oublié que des conventions existaient déjà sur Portal:Fr/MediaWiki. Donc comme il n’y a clairement pas une majorité en faveur du changement de ces règles, on reste à l’ancienne règle qui dit NBSP partout.

OK pour prendre les conventions typo de Wikipédia, mais uniquement pour tous les cas que nous n’avons pas tranché ici (en l’occurrence, l’apostrophe courbe fait consensus sur Translatewiki.net alors qu’elle n’est pas forcément recommandée sur Wikipédia).

Un consensus pour NBSP semble se dessiner, il est dommage que Verdy p continue à insister en partant en guerre d'édition (après avoir été bloqué deux fois).

Si tu traduisais autant et corrigeais des fautes réelles, mais non, tu as lancé cette guerre toi-même en reprenant de façon systématique sans rien corriger autour. En attendant il y a des milliers de traductions jamais relues avec des tas d'erreurs d'interprétations ou de fautes d'orthographe. Mais là tu ne fais QUE des reverts tu n'avances à rien dans ta propre guerre d'édition dont tu es toi-même à l'origine...

Remettre systématiquement l'espace fine insécable alors qu'il y a consensus pour utiliser l'espace insécable fait perdre du temps à tout le monde.

Consensus ? Cela ne posait aucun problème depuis longtemps, jusqu'à ce qu'un utilisateur de Mac ou Apple se mette à s'en plaindre à cause d'un bogue Apple et d'une mauvaise configuration de navigateur avec une police qui n'a jamais été faite pour le web (on ne traduit pas du tout pour l'UI propriétaire d'un OS utilisant une police propriétaire très spécifique qui est la seule à avoir ce problème et ne correspond même pas aux spécifications données par Apple). "Trop de problèmes" alors que c'est une très faible minorité d'utilisateurs et que les typographes depuis longtemps utilisent des règles précises sur Mac et jamais n'ont utilisé les polices propriétaires Apple dans leurs publications. Faire le forcing pour utiliser les polices propriétaires et nier les recommandations, alors qu'Apple lui-même a reconnu l'anomalie (survenue de façon inattendue lors d'une mise à jour d'une seule police, pas en cohérence avec la mise à jour du moteur de rendu pour être compatible avec diverses versions de MacOS ou iOS qui ont reçu cette police "corrigée" qui ne leur était pas destinée; Apple s'est planté dans son système de versionnement, pourtant d'autres navigateurs même pour Mac n'ont pas ce problème, même si Apple les oblige à utiliser le moteur de rendu, masi certainement pas la police propriétaire Apple dans les publications non-Apple); même Apple publie des documents non destinés aux Mac/iPhones (exemple iTunes et QuickTime sous Windows, et pour des navigateurs non-Apple: Firefox, Chrome/Chromium, IE, Edge). Apple tarde à corriger ce bogue oublié mais ne va pas avoir le choix pour la prochaine version d'Unicode où le problème est maintenant bien documenté et nécessite une action nécessaire pour diverses autres langues (le "hack" Apple initialement utilisé pour le mongol, qui nécessaitait un moteur spécifique même pas supporté dans les versions anciennes pourtant supportées encore par Apple pour MacOS et iOS est abandonné, l'écriture mongole ayant maintenant des règles précises et approuvées même par Apple; il n'y a eu aucune modification en revanche pour NNBSP qui reste une fine insécable, maintenant séparée de l'utilisation boguée en écriture mongol qui utilise un autre caractère, déjà codé, mais dont les règles sont maintenant plus précises, notamment pour la présentation verticale de cette écriture, mais aussi du fait que le nouveau caractère est orthographique et non seulement typographique et ne peut pas fonctionner exactement comme la fine insécable).

« très faible minorité d'utilisateurs »

Safari est le deuxième navigateur en termes de parts de marché devant Firefox, je doute que ce soit une « très faible minorité d'utilisateurs ».

« Cela ne posait aucun problème depuis longtemps, jusqu'à ce qu'un utilisateur de Mac ou Apple se mette à s'en plaindre »

À vrai dire, c'est vous qui aviez commencé à faire des remplacements en masse en septembre-octobre. C'est à ce moment-là que je me suis rendu compte de l'absence d'espaces avant les signes de ponctuation dans les messages de MediaWiki.

Ce serait bien de citer des références dans vos pavés et si possible les aérer pour une meilleure lisibilité.

Puis j'ai déjà démontré avec une police libre et autre que celles fournies par Apple qu'il y avait bien un problème avec la gestion de l'espace fine insécable dans Safari (pas macOS, Safari, merci d'éviter les digressions).

Non c'est fait depuis beaucoup plus longtemps (même avant l'introduction de l'anomalie de MacOS 8, les versions antérieures n'ayant pas ce problème). Et je persiste que même si Safari est le navigateur le plus utilisé sur iPhone et Mac, ce sont aussi des plateformes minoritaires, et la police système correspondante n'est absolument pas imposée et n'est pas destinée au web, la grande majorité des sites web s'en passent car ils ne visent pas spécifiquement ces machines Apple, même en mobile.

Comment le dire, quels que soit le nombre d'arguments, il n'y en a jamais assez et pourtant on vient me reprocher un "pavé"...

Et je ne digresse pas en parlent de MacOS ou iOS, les seules plateformes où le moteur de rendu seulement est imposé, pas les polices. Safari, même sous Windows ou Android, n'a pas ce problème tout bonnement parce que cette police propriétaire Apple problématique (issue d'une mise à jour incohérente uniquement sur les systèmes MacOS et iOS, mais pas dans Safari lui-même même sur ces plateformes) n'est pas utilisée du tout (donc certainement pas imposée non plus), malgré le fait qu'il utilise ce moteur de rendu de texte de Safari, adapté seulement aux systèmes de polices de chaque plateforme. Et nombre de bibliothèques sont communes (dont ICU qui fait usage directement de la fine dans ses données, même celles distribuées sur ICU pour MacOS et iOS).

Comment le dire que c'est uniquement un problème d'une unique police propriétaire, spécifique à MacOS et iOS (pas à Safari), et jamais faite pour le web (pas plus que le logo Apple présent dans un PUA de cette police mais non codé de façon standard dans Unicode et pas utilisé non plus sur le web homis dans des pages spécifiques pour MacOS pour documenter l'UI de MacOS et uen touche de son clavier spécifique)?

Rappel

Que Verdy_p soit d'accord ou pas puisque la règle locale est d'utiliser  , il faut utiliser  .

Historique

Si tu le faisais avant et que ça ne posait pas de problème et que maintenant ça pose un problème c'est bien qu'il y a un problème actuellement à ne pas utiliser  . C.Q.F.D.

Répétitions

Tu pourras dire et répéter dix, cent, mille fois tes arguments un jour il faudra te rendre compte que certes tes pavés peuvent être indigestes mais fondamentalement on n'est pas d'accord : ce n'est pas parce qu'il s'agit d'une minorité d'utilisateurs qu'il faut les brimer.

Il y a 2,6 % d’utilisateurs de Safari et 19 % d’utilisateurs de Safari mobile parmi les visiteurs des sites Wikimedia selon Analytics.Wikimedia.org.

La capture d’écran de Thibaut montre bien que le bogue se produit avec d’autres polices que celle par défaut du navigateur.

Moi j’ai aussi l’impression que la guerre de modification, c’est toi qui l’a lancée, Verdy_p (aurais-tu un diff qui prouve le contraire ?).

De toutes façons, maintenant, il y a suffisamment de personnes qui se sont exprimées ici pour considérer l’utilisation de NBSP comme une règle, jusqu’à ce que ce bogue de Safari devienne vraiment minoritaire.

Non je ne l'ai pas lancée, NNBSP a été là depuis des années avant qu'un utilisateur s'en plaigne sur son mobile ou mac spécifique avec des versions spécifiques de l'OS et une mise à jour malencontreuse par Apple d'une police sur ces OS. Maintenant "on" a prétendu que mon argument "minortiaire" était faux mais pourtant c'est la réalité. Si à chaque fois qu'un OS commet une bévue on doit revenir sur les mauvaises pratiques du passé alors que les autres dans leur immense majorité ont réglé le problème depuis des années, où va-t-on : retour à l'ASCII partout, suppression des accents en français, et on fait des fichiers tout en capitales comme l'INSEE, et même sans ponctuation comme La Poste ???