Espaces fines

Bonjour,

À la demande de Nemo_bis, j'ouvre une discussion ici.

Comme je l'ai indiqué ici, les espaces fines insécables (U+202F) posent problème sur les appareils sous iOS et sur Safari sous macOS où l'espace est tout simplement invisible.

Il me semble donc que pour le moment, pour des raisons de compatibilité, il faudrait plutôt utiliser des espaces insécables normales (U+00A0) à la place.

Des avis ? (Évitez de faire des pavés et pensez à aérer votre texte).

EDIT : Pour rappel, Safari est le deuxième navigateur en termes de parts de marché ([1]).

Ping Lyokoï, Jules78120, VIGNERON, Gomoko, Wladek92, Urhixidur et Verdy p.

Je ne connais pas la norme ou ce qu'il faudrait faire, mais si un des caractères ne passe pas, il ne faut pas l'utiliser.

Je répète mon opinion d’hier, puisqu’elle n’a probablement été consultée que par Thibaut (T60529) : une partie non négligeable des francophones n’insérant en général pas d’espace à ces endroits, les deux options proposées (1. Tout le monde a une espace mot insécable ; 2. la majorité a une espace fine insécable, mais une partie a une absence d’espace) me semblent aussi bonnes (ou mauvaises) l’une que l’autre.

J’ajoute que, à supposer que verdy_p surinterprète la très légère différence d’espacement (cf. discussion précédente), les développeurs de Safari auraient manifestement fait un choix délibéré (on s’attend dans le cas contraire à un caractère de remplacement, pas à un non-affichage). En ce cas, choisir l’espace mot insécable revient à contredire un choix que j’espère cohérent dans l’écosystème en question (et que je ne connais pas assez pour juger). L’intérêt pour ces utilisateurs de choisir l’option 1. me semble alors à tout le moins discutable.

If the narrow non-breaking space is used on iOS/non-supporting device, what will I see if I copy and paste the translation to plain text? "Abc : def"? Or "Abc: def"? Is that a potential problem?

On iOS, you'll get the string of characters "Abc : def" displayed as "Abc: def" ([1]) and yes the lack of space is a problem in French.

If I understand this correctly, then:

• If we say "Abc <nbsp>: def", and I copy it, and paste it into another document, then I will get "Abc : def" (which is good).
• If we say "Abc <nnbsp>: def", and I copy it, and paste it into another document, then I will get "Abc: def" (which is not good, right?).

If I understand this all correctly, then I prefer the one that copies/pastes better. (I don't know whether others will think that is important, but it would be a little helpful to me.)

copy-pastes are NOT removing spaces even if they are nbsp or nnbsp. If this ever happens on a nay device this is a clear violation of standards and a sever bug that may occur on some old versions using incorrect or very antique Unicode databases or making false assumptions.

I've tested on MacOS 13 and 14, both NBSP and NNBSP are supported and work as expected. I've not seen any one silently removed or replaced by SPACE, or not rendered as empty (except in monospaced consoles where NNBSP **may** be invisible but still unbreakable, or consoles using legacy non-Unicode 8-bit charsets like MacRoman, where NBSP may be replaced by SPACE and NNBSP may be dropped)

If you use legacy apps that generate texts not saved in UTF-8 but in legacy charsets (MacRoman, ISO8859-1,Windows1252, CP850, US-ASCII, TISCII, VISCII, TIS620, HKCS, GBK, SJIS,...), the NNBSP may then be dropped and this is not a defect, but NBSP will be replaced by SPACE where needed if the legacy charset maps no NBSP: this is a conversion, not a transcoding, it may be lossy in that case when the legacy charset is not supporting the whole UCS

---

(note: GB18030 supports the whole UCS, so even if GBK did not, this should no longer occur with GB18030 which is UCS-compliant and can be used now as a conforming UTF even if GB18030 is not defined in the Unicode standard itself but by the PR Chinese standard; GB18030 is not part of the Unicode standard because it also allows other extensions or distinct duplicate encodings that are not mapped to any UCS position, but there's a& GB18030 subset that is bijectively liked to the UCS and this bijection is now warrantied to be stable even in the PR Chinese standard; GB18030 was even amended to explicitly say that these extensioçns are now deprecated adn their support is NOT mandary in any GB18030-conforming application; this means that any Unicode-conforming application is now GB18030 conforming and the reverse is true as well for all newer GB18030 applications that chose to no longer honor the legacy extensions which were part of the unamended GB18030; this also means that the PR Chinese government no longer needs to maintain its own encoding standard, all is done in the UCS directly, along with the work made in the IRG working group for the ideographic script subset in the UCS and coordinated with relevant national standard bodies in PR China, Taiwan, Singapore, North and South Korea, Vietnam, Japan, Thailand, Burma, Mongolia, Russia and other countries having officially recognized Chinese-speaking communities, or with international organizations needing support for modern Chinese, Korean and Japanese, or for educational bodies like linguistic departments of universities).

Did you test this on iOS (i.e., on an iPhone or iPad)?

Thanks Verdy for engaging in the discussion. Please refrain from changing spaces while the discussion is ongoing and then abide by the consensus.

@Nemo_bis: Unfortunately, he keeps changing spaces: [1][2][3][4].

Oui pour le U+00A0 évidemment. U+202F est théoriquement meilleure du point de vue typographique (et encore) mais pose bien trop de problème.

Bonjour à tout le monde,

On m'a invité a donner mon avis, alors j'ajoute mon « grain de sel » ← avec des espaces insécables. Pour moi, la réponse est simplissime. Tout d'abord, à la vue des participants à cette discussion, nous parlons tous de Wikimedia ← sans accent. C'est important, car TW accueille beaucoup de projets et tous appliquent leurs propres règles. Donc si on veut faire une traduction de Phab, de MW, de WD, etc. en français, il faut appliquer les règles locales. En occurrence, les règles locales sont celles de wikipedia:fr:Wikipédia:Conventions typographiques et elles sont indépendantes de toutes règles extérieures, quand bien même elles s'en inspirent. Si une traduction est proposée dans une autre langue, ce sont les règles locales dans cette langue qui s'appliquent. Pour rappel: il s'agit d'un espace insécable qu'il faut utiliser, soit U+00A0 en Unicode (nbsp). Maintenant, si vous parlez de traduire un projet extérieur à WM comme https://mifos.org/, je n'ai auncun avis.

Petit addenda, il faut utiliser aussi l'accentapostrophe droite et les guillemets en chevrons (guillemets français). Je croise trop souvent ces erreurs. Vos préférences ou avis ci-dessus doivent aussi changer les règles sur frwiki. Sans cela, vous n'avez pas d'autre choix, il me semble. Dites-moi si je fais fausse route ?

Note: "l'accent droit" n'existe pas (en tout cas nulle part en français).

Et sinon l'apostrophe ASCII n'est requise sur Wikipédia QUE dans les titres d'articles (qui ont leurs propres limites techniques y compris en terme de présentation et de capitalisation, et qui d'ailleurs n'admettent même aucune espace insécable, ni aucun tiret de soulignement ASCII et d'autres caractères ASCII réservés), pas dans les textes qui sont libres et doivent utiliser les formes typographiques normales.

Merci de ne pas confondre donc

• les contraintes sur les titres d'article (même si on peut en changer l'apparence de façon très limitée, uniquement concernant la capitalisation de la première lettre et l'enrichissement par une mise en forme CSS ou des attributs ou balises HTML "inline" avec "DISPLAYTITLE:", toute autre modification des caractères étant proscrite et rendant DISPLAYTITLE nul et totalement ignoré, même lors de son inclusion par un modèle : ceci est signalé d'ailleurs par une bannière d'alerte dans l'éditeur Wiki en mode prévisualisation) et
• celles sur le reste du contenu qui n'a de contrainte que sur les balises HTML autorisées (uniquement une partie de celles de HTML4, aucune de celles ajoutées dans HTML5) et sur les attributs interdits (scriptables ou de liens externes avec href="..." également scriptable) ou encore les URLs autorisées (seuls certains préfixes de schémas sont autorisés pour les liens externes, "file:" et "javascript:" sont interdits et filtrés par exemple, de même que les schémas de commande d'applications externes: ces liens ne peuvent être qu'affichés (pour une utilisation par un "copier-coller" manuel vers la barre d'adresse ou un outil externe, mais jamais actifs et cliquables directement dans le navigateur).

Dans le contenu, tout texte Unicode valide dans un élément HTML de texte (hors des balises elle-même, ou dans la valeur textuelle des attributs de balises autorisées) sera accepté (cela n'exclut que certains caractères de contrôle, et les caractères de contrôle des sauts de lignes sont unifiés: CR, LF, CR+LF, LS, PS, les autres sont éliminés ou invalides comme NUL), y compris en cas de tentative de contournement via des références numériques de caractère. C'est issu du standard HTML4 et maintenu en HTML5. De plus ce contenu textuel doit pouvoir être normalisé en forme NFC, NFD sans aucune conséquence sur l'affichage, mais aucun autre filtrage n'aura lieu (donc pas de normalisation NFKC ou NFKD qui se fait avec perte d'information). Les seuls caractères Unicode interdits sont les "non-caractères" (y compris les "surrogates" non appairés, non valides dans tous les codages UTF), et la plupart des contrôles C0 et C1 (hormi ceux des sauts de ligne, qui sont automatiquement unifiés, ou ceux de tabulation, qui sont traités comme des espaces simples dans la plupart des éléments HTML et unifiés et compactés en une seule espace, sauf dans des balises comme "pre" contenant du texte non balisé mais pré-mis en forme et ne dont aucun code wiki ne sera analysé, ou comme la balise "source" dont le contenu est analysé par un parseur spécial pour sa remise en forme automatique).

De fait les codages non-Unicode contenant des séquences d'échappement ne sont pas autorisés du tout, même en essayant d'utiliser une référence numérique pour des contrôles C0 comme ESC, ou DLE, ce qui inclut les codages asiatiques ou codages pour terminaux/consoles VT100 et dérivés et toute séquence destinée à gérer un tabulateur ou la position dynamique d'un curseur d'entrée de texte ou encore la délimiation de zones de saisie sur un écran de formulaire, ou la gestion d'une ligne d'état). Cela est compatible avec Unicode, mais pas avec HTML4 donc pas non plus en wiki (et même si le wiki génère ensuite du HTML5 qu'il refuse cependant d'accepter en entrée).

Tout le reste c'est du contenu binaire qui ne peut être mis que dans un "fichier" avec un des types MIME autorisés par Wikipédia ou Commons et dont le contenu sera vérifié par des outils automatiques (qui peuvent aussi éliminer des parties sensibles ou des fragments exécutables ou scriptables interdits, ces modifs automatiques notamment dans les PDF ou images/photos/vidéos et clips sonores étant permises par les licences requises : si ces modifs surviennent elles annuleront les empreintes numériques, mais pas les métadonnées d'auteur ou de licence).

Dernière précision : ces règles de wikipedia.fr concernent le contenu de fr.Wikipedia, et n'ont rien à voir avec la localisation de MediaWiki lui-même qui est indépendante de tout wiki. Il y a plein d'autres wikis basés sur MediaWiki qui utilisent l'interface française: ici on traduit l'interface, pas les contenus.

L'interface est destinée à être affichée directement, mais pas modifiée sur le wiki lui-même (même si certaines de ces traductions sont stockées dans la base de données, c'est dans un espace restreint inaccessible à quiconque hors des administrateurs qui peuvent y toujours y mettre autre chose que ce qui vient de MediaWiki, et empêcher l'écrasement en bloquant ces pages pour que l'import n'y touche pas (généralement cela se fait pour ajouter ou modifier des contenus destinés à expliquer la politique locale à fr.Wikipedia ou à donner des liens d'aide spécifique).

Sinon il y a les extensions de MediaWiki dont bon nombre ne sont même pas présentes sur fr.Wikipédia mais pourtant traduites en français car elles sont utilisées sur d'autres wikis (pas tous d'ailleurs sur les wikis de Wikimedia, ou sur des wikis très spécialisés et techniques ou fonctionnant en groupe fermé avec des besoins très spécifiques au groupe fermé et des règles de confidentialité ou contractuelles très différentes, ces wikis ne sont pas liés par l'identification SUL, les comptes utilisateurs sont totalement séparés, les règles applicables au contenu et même aux licences sont également très différentes et il peut y avoir des contenus sous licence propriétaire dans de tels environnement; les règles lingusitiques adoptées sur le profile fr.wikipedia public ne s'appliquent pas du tout à ces wikis public ou privés, et avoir des exigences linguistiques bien supérieures à ce à quoi se limite fr.Wikipedia). Bref fr.Wikipedia ne régit rien ici et ici on n'a pas besoin de ces approximations de contenus actuellement soutenues par fr.wikipedia.

D'ailleurs concernant les apostrophes tu t'es bel et bien trompé en lisant les recommandation de contenu fr.wikipedia un peu trop vite en diagonale.

Et note aussi que ces préconisations ne s'appliquent pas non plus à Wikidata, ni à Commons, ni encore à fr.wiktionary ou fr.wikisource qui utilisent pourtant les traductions faites ici et qui exigent une typographie bien plus précise et soignée (qui à terme doit aussi orienter ce à quoi devrait aboutir aussi les contenus de Wikipedia (et ne me dit pas que le Wiktionnaire, Wikisource ou Wikidata sont des projets mineurs dont tout le monde se fout (sachant aussi que Wikidata a des utilisations de plus en plus nombreuses hors de Wikimedia, y compris dans des applis officielles et scientifiques, et qu'il sert aussi à orienter largement ce vers quoi tend Wikipedia sans être contraint non plus par les exigences de la Wikipédie anglophone; d'ailleurs Wikidata n'utilise pas les restrictions sur les titres de pages qui n'y sont que des identifiants numériques, le reste étant traduit dans des libellés et descriptions indépendants et entièrement multilingue, supportant toutes les écritures et nombre de variantes dialectales ou orrthographiques; de même Wikidata ne tient pas compte des limites des codes interlangues, en fait les sous-domaines, entre projet wikimedia, et Wikidata veut respecter le standard BCP47 à la lettre contrairement aux codes interwikis non conformes; de même OSM ne veut pas des codes interwikis de Wikimedia, sauf pour lier aux articles des wikis de Wikipedia et tout le reste devant être conforme à BCP47; le Wiktionnaire aussi ne veut pas des codes interwikis pour ses propres traductions locales à chaque édition qui supportent beaucoup plus de langues et écritures) !

Conclusion: fr.wikipedia ne régit pas les règles des traductions faites ici, même s'il oriente assez fortement les choix terminologiques (cependant dans une optique de la localisation de MediaWiki et assez peu concernant les contenus de Wikipedia dans les traductions françaises faites ici). Pour le reste c'est à fr.Wikipedia de gérer ses choix locaux sur son propre wiki et il doit se coordonner sinon avec les autres wikis et n'est pas en droit de décider tout seul avec ses propres décisions biaisées par une audience bien plus limitée. D'ailleurs nombre d'utilisateurs de Mediawiki ne veulent utiliser aucun contenu de fr.wikipedia et n'y contribuent pas du tout (ou très épisodiquement) alors qu'ils sont très actifs sur d'autres wikis (sur Wikimedia ou ailleurs).

S’il te plait, Verdy_p, pour faciliter le débat, reste aussi concis que possible et évite les digressions, on y gagnera vraiment en clarté.

Question : désormais tu préfères ne plus mettre d’espace du tout ???

En tous cas, merci de ne plus faire de modifications d’espace tant que le débat n’aura pas été réglé. Ce n’est pas à coup de révocations que le débat va être réglé…

Je n'ai pas voulu supprimer ces espaces. Si ça a eu lieu à un endroit c'est un problème d'interface car ils y étaient bien quand j'ai saisi ça (filtrage par l'interface de traduction?).

Cinq personnes (en comptant l’autre discussion) se sont prononcées en faveur d’NBSP, il serait temps d’en prendre acte et de passer à autre chose.

Au cas où, +1 aussi. Vigneron a bien résumé mon opinion.

Idem (je n'ai rien contre les espaces fines, mais une espace insécable est largement préférable à pas d'espace du tout).

Mai il y a bien une espace ! Bel et bien pris en charge par MacOS depuis une douzaine d'années (pratiquement depuis son introduction dans Unicode 4.0). Et utilisé sur MacOS depuis bien longtemps (avant même le web) par tous les pros de la typographie et de la PAO (qui travaillent depuis bien plus longtemps sur Mac que sur PC) avant même le développement du web, ils ont été nombreux à demander cette prise en charge qui est arrivée au même moment que son unification (à tord) aussi avec le séparateur en mongol. et MacOS prend en charge aussi le mongol (pour l'instant encore avec NNBSP mais cela va changer en mars prochain avec un nouveau caractère et Apple a aussi déjà fait une mise à jour bêta pour ça de ses OS (il ne supprimera pas NBNBSP en mongol mais l'utilisera en mode de compatibilité sans rien retirer de la fine insécable, qui reste encore standard comme séparateur de groupes de chiffres dans les nombres en format français et ISO, où l'espace insécable NBSP est totalement indésirable) et figure aussi dans les bibliothèques CLDR et les formateurs de nombres en français de MacOS et de Java (inclus aussi dans MacOS et iOS).

Pour ce qui concerne macOS, on parle ici de Safari qui n'affiche clairement pas d'espace (prouvé plusieurs fois dans la discussion précédente), pas des autres applications ou navigateurs.

Merci de ne pas changer de sujet.

Console Javascript:

console.log(new Intl.NumberFormat('fr-FR', { maximumSignificantDigits: 3 }).format(123456));

Affiche "123 456" et non "123456".

console.log(new Intl.NumberFormat('fr-FR', { maximumSignificantDigits: 3 }).format(123456).codePointAt(3).toString(16));

Affiche "202f" (code hexadécimal du 4e point de code), et non pas "a0" ni "34".

Intl.Numberformat() est complètement supporté depuis Safari 10, Chrome 24, Edge 12, Firefox 29, IE 1, Opera 15.

Comment font alors le Mac or l'iPhone?

Voici le résultat sur Safari 13.0.3 (macOS), si j'en crois le résultat pour la même commande sur Firefox, Safari semble ignorer complément l'espace fine insécable qui est censée être entre 120 et 000.

Non Safari ne l'ignore pas puisqu'il affiche bien "202f" comme 4e caractère, il choisit seulement de l'afficher comme un glyphe vide (choix de design d'Apple dans la police que tu utilises). Ce qui confirme ce que je dis: c'est son design et conforme à ce qu'Apple fait depuis longtemps aussi dans la présentation des nombres. Le caractère est bien présent, mais il n'y a pas d'anomalie d'affichage, aucun "tofu".

Note bien que dans ta console Freifox, les résultats sont affichés dans une police de type "monospace" (à chasse fixe) qui figure le NNBSP sous forme d'une espace simple et non d'une espace vide (les deux sont possibles, bien qu'à mon avis la fine est plus adaptée à ce cas). Si tu passes la console en police proportionnelle tu peux voir une différence suivant les préférences du navigateur pour les deux styles génériques "serif" ou "sans-serif", selon les polices choisies (si tu prends une police système Apple, en sans-serif, le NNBSP disparaît et c'est normal et cohérent avec les glyphes des ponctuations). Dans tous les cas c'est une question de préférence: si tu aimes les polices UI d'Apple, ne rien voir est normal car tu ne vois rien non plus dans l'UI d'Apple pour les grands nombres et il n'uy a non plus aucune espace ajoutée autour des ponctuation déjà "élargies" de ces polices, donc aucune anomalie là non plus, mais tu ne fais pas de la APO ou de la typographie. Tu as le choix dans ton navigateur (dans Safari, comme Firefox ,ou Chrome, ou Edge qui va aussi arriver, ou Opera) !

Et dans d'autres polices comme Times New Roman, Segoe UI et plein d'autres, le caractère est bien distingué.

Critique l'UI d'Apple si tu veux, mais c'est ce qu'Apple recommande. De même il a mappé NNBSP (pas seulement NBSP) sur le clavier français tout en sachant que ce peut ne pas être utilisé pour les UIO d'applis MacOS/iOS, mais que c'est bien utilisé dans les contenus en ligne et la PAO. Hors de Javascript tu peux aussi voir ce que retourne les API d'internationalisation des nombres de MacOS: là aussi il y a bien NNBSP et non NBSP (Apple ne dévie donc pas des normes de codage, son choix est purement typographique dans ses polices système).

Apple a du faire ça pour "compacter" les nombres sur les mobiles (on peut noter qu'il choisit des chiffres plus larges, en supposant qu'il n'y a jamais besoin de les compter, il a fait le même choix avec les ponctuations qui incluent un "gap" qu'Apple juge suffisant pour qu'avec la même police la fine puisse être annulée. On peut critiquer le choix d'Apple mais c'est un choix propriétaire pour ses polices UI (qui ne sont pas destinées au rendu web où il y a plein d'autres choix que la police "système". Et c'est aussi cohérent avec son choix d'interface pour la présentation des formulaires de ses applications.

Ces polices système ne sont pas destinées au web, à la typographie fine, à la PAO. Dans le Finder de fichiers, MacOS choisit de ne pas afficher les grands nombres mais il les arrondit pour ne pas avoir à afficher les groupements de 3 chiffres. La PAO, et les logiciels tiers comme MS Office ou Libre Office utilisent des polices qui font clairement la différence et les polices "système" (pas adaptées à toutes les langues mais à des orthographes simplifiées, y compris en Arabe ou hébreu) ne sont pas utilisées sauf si on les demande.

Note: les polices web par défaut sont normalement avec "Serif" dans le texte d'un navigateur. Pour l'UI le design original d'Apple et cohérent avec son interface est de ne pas afficher les NNBSP (ce qui est une erreur fondamentale pour l'écriture mongole, ce qu'Apple a fini par reconnaître). Attends le printemps prochain, Apple va changer ça dans ses mises à jour de MacOS et iOS et rétablir ce qu'il faisait au début quand NNBSP a été encodé, mais pour il mettra un "flag" de compatibilité pour les applis spécialement dédiées à MacOS, pas pour le web (à moins d'utiliser un "feature" OpenType spécifique activable en Javascript pour émuler le comportement des versions récentes boguées de MacOS et iOS avec ses polices système).

As-tu une source concernant cette mise à jour de mars ?

Impossible de voir les réponses au delà du niveau d'indentation (bogue connu de LiquidThread). En tout cas, Apple lui-même ddéfinit bien NNBSP, il l'affiche aussi mais c'est un bogue dans sa police système UI qui n'affiche plus rien depuis MacOS8 avec cette police qui a été modifiée pour des versions de MacOS ultérieure (qui n'ont pas besoin de mapping), mais distribuée à tord sur des versions anciennes (qui demandaient encore un mapping explicite du caractère avec les anciens moteurs). Ca marche sur les autres polices car elles sont au courant du bogue et ont conservé un mapping de NNBSP. Et opn voit que tous les navigateurs pour Mac ne font pas la même chose et contournent ce bogue qui en est bien un sur certains Macs et iPhones). Mais Apple n'a pas changé ses recommandations. Son rendu avec sa police système propriétaire ne marche pas, mais sur le web rien n'oblige à utiliser cette police (Apple est tout aussi mauvais pour formater correctement les grands nombres dans son propre tableur en français ou dans les langues utilisant le format ISO standard, où ni la virgule ni le point ne sert de séparateur de groupe, mais un NNBSP est décrit comme neutre et ne souffre aucune des ambiguïtés entre séparateur décimal ou séparateur de groupe selon les langues et usages; le NNBSP est également standard dans les pays bilingues français/autre comme le Canada ou la Belgique ; la Suisse est originale en proposant l'apostrophe verticale comme séparateur de groupe, mais c'est peu utilisé). Le NNBSP n'est pas une "lubie" personnelle, elle est décrite dans de nombreux standards et soutenue aussi par Apple, même s'il a un bogue dans certains rendus (un bogue facilement contournable: la police système UI n'est de toute façon PAS conçue pour le contenu web et Apple a déjà convenu de régler ça cette année avec la sortie d'Unicode 13 au printemps et aussi ses propres remraques concernant le codage de la langue mongole où Apple est directement mentionné comme ne respectant pas un standard nécessaire). Et contrairement à une légende, l'introduction de NNBSP dans Unicode 4 était concomitante avec le premier encodage de l'écriture mongole mais n'était pas liée uniquement à son usage en mongol (un usage qui persiste encore mais qui va être bientôt abandonné): il se trouve seulement que pour le mongol il avait été décidé (à tord) d'unifier le séparateur de voyelle mongole avec la fine insécable; le séparateur mongol (MVS) a depuis été codé, mais il va être généralisé (NNBSP sera officiellement déprécié en faveur de MVS uniquement pour cette écriture, mais pas pour le reste: la fine reste une fine soutenue par l'ISO et les typographes pour diverses langues, y compris en anglais, et pas seulement le français et standardisée par CLDR et Unicode, présente dans ICU; et cela a été reconfirmé et renforcé partout dans CLDR là où elle manquait encore). Bref c'est un faux problème: ceux qui ont les moyens d'acheter du matériel Apple le font en connaissance de cause, et ceux qui pinaillent pour voir une espace peuvent le faire avec un réglage très simple du navigateur ou les préférences du wiki., ou avec toutes sortes d'outils de personnalisation pour leur smartphone (Apple n'impose pas du tout ses polices système pour tout et surtout pas le contenu dont il n'est pas à l'origine: applis tiersces et contenus web comme c'est le cas ici; et aucun typographe ni aucune publication n'utilise les polices système propriétaires d'Apple sans violer les droits d'auteur d'Apple).

Comme dit plusieurs fois, il n’est pas possible de changer la police dans les préférences de Safari, ni sur les autres navigateurs sur iOS qui sont forcés d’utiliser le même moteur de rendu que Safari.

J’ai proposé un compromis qui a été accepté par plusieurs traducteurs, s’il y a quelqu’un qui pinaille c’est plutôt vous sinon cette discussion aurait déjà été close.

Ils sont forcés d'utiliser le moteur de rendu, pas forcés d'utiliser les polices système (pas plus que les auteurs de sites webs comme ici). Ces polices systèmes n'ont jamasi été conçues pour produire du contenu, le web est nécessairement ouvert à d'autres appareils que ceux (bogués et chers) d'Apple. Et ça fait longtemps que les typographes utilisent des Mac mais jamais les polices Apple trop limitées: ils en ont de bien meilleures et ont des règles linguistiques et typographiques bien plus précises que ce que demande Apple pour l'UI priopriétaire de son OS uniquement, mais pas du tout pour les contenus.

Il faut tenir compte non seulement de l'idéal, de ce que peut faire la machine mais ce que fait la machine par défaut car dans 99% des cas l'utilisateur sera dans ce cas.

Et donc la logique veut qu'on utilise l'espace insécable de largeur normale et non l'espace insécable fine. Car entre afficher une espace un peu trop grande et pas d'espace il n'y a pas photo.

Choix révisable dans quelques années si l'espace insécable fine est correctement affichée partout.

Je viens de faire un test avec des polices autres que celles d'Apple et là non plus l'espace fine insécable ne s'affiche pas (alors qu'elle s'affiche sur d'autres programmes sur macOS).

On peut d'ailleurs remarquer des "tofu" avec la police libre DejaVu Sans Mono.

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 &nbsp;, il faut utiliser &nbsp;.

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

Bonne nouvelle : le bogue est enfin corrigé dans iOS 14 et Safari 14 sur macOS qui ont été publiés le 16 septembre.

J'ai annulé mes remplacements effectués après cette date.

Donc on autorise NNBSP ? Et est-ce qu’on permet le remplacement massif de NBSP par NNBSP ? (Si oui, mieux vaut demander à un robot de le faire et avec le drapeau robot afin de ne pas notifier tous les utilisateurs sinon ça va inonder des tas de boites de courriels…

Pourquoi pas mais en faisant attention à ne pas le faire bêtement : les signes appariés tels que les guillemets ont, côté "intérieur" des espaces insécables de largeur standard et non des espaces fines si j'ai bien suivi le fil. Et bien-sûr des espaces ordinaires à l'extérieur le cas échéant.

Peut-être résumer le fil sur un espace (et non une pour ceux qui ont suivi ;-)) de projets wiki ? Car si les différents projets sont en phase ça évite les erreurs parce qu'on participe à un projet autre.

Mon résumé en trois phrases :

1. Les systèmes actuels supportent les nnbsp; qui correspondent à la règle typographique française pour les signes typographiques doubles tels que ; : ! ?.
2. Êtes-vous d'accord pour respecter cette règle ?
3. Vous opposez-vous à ce qu'un robot fasse la modification proprement (en respectant les espaces insécables des caractères appariés tel que le guillemet) ?

Pour l'intérieur des guillemets la fine est également en usage recommandé par nombre d'éditeurs de presse (au même titre que comme séparateur de groupes de chiffres, ou à côté des autres signes de ponctuation. Pour les deux-points, il y a deux usages (fine ou demi-cadratin) selon les éditeurs (certains recommandent la fine d'autre le demi-cadratin mais cela dépend du choix typographique des polices utilisées (en général avec les polices à empattements on préfère le demi-cadratin, mais sur le web ou les mobiles et l'affichage à l'écran en général les textes sont en polices sans empattement et la fine s'impose alors).

Les éditeurs de presse ou de livre historiquement utilisaient beaucoup les polices à empattement, mais c'est de moins en moins utilisé, et étant donné les métriques des polices modernes sans empattement, d'origine anglophone où la chasse entre les œils (non il n'y a pas de faute d'orthographe pour ce sens ce n'est pas "yeux") est moins large qu'en typographie française classique (ce qui explique l'usage de l'espace cadratin après un point de fin de phrase chez les anglophones, donc du "double espace" sur les anciennes machines à écrire à chasse fixe, où le point était en fait bien plus "épais" qu'il ne l'est aujourd'hui, simplement pour éviter de percer le papier lors de la frappe ou laisser assez d'encre pour qu'il soit visible sur une papier de mauvaise qualité et une encre pas forcément très homogène !), pour mieux se rapprocher de la typographie française avec les polices proportionnelles anglophones à chasse "serrée", on peut préférer l'espace demi-cadratin au lieu de la fine avant les deux-points.

Il faut bien voir que tout ça est une adaptation, et que cela dépend des métriques de conception des polices utilisées. Hors sur nos wikis et le web en général on a très majoritairement et par défaut des métriques anglophones et un contenu en polices sans empattement (pour la lisibilité sur des écrans à faible résolution, souvent bien plus faible que les 300 dpi, au moins, de l'impression soignée des publications des éditeurs).

Et il ne faut pas oublier pour quoi et par qui ont été écrites les "règles" typographique : d'abord pour des éditeurs de documents imprimés qui maitrisent les polices utilisées et leurs métriques, alors que nous on travaille sur des documents en ligne dont on ne connait pas du tout les métriques et où on ne connait pas non plus la résolution de rendu. Il faut être donc prudent... sans aller non plus vers l'excès en croyant à un rendu de type "machine à écrire" quand plus personne ne les utilise (et même si on a un rendu avec une police à chasse fixe, que ce soit une fine ou une espace demi-cadratin ne fera aucune différence visible, la police étendant la largeur de toute façon). Masiç condmaner tout le monde à des espaces insécables plus larges que nécessaire est assez stupide pour les deux-points ou les guillemets.

Pour les guillemets, ce n’est pas ce que recommande le Lexique des règles typographiques en usage à l'Imprimerie nationale ou l’OQLF (voir aussi ici), mais je ne vais pas insister.

Encore une fois tu te bases sur des recommandations pour les imprimeurs avec leurs polices de caractères dédiées (et avec empattements et en métriques francophones)... Sur le web iou la lecture à l'écran c'est différent (résolution faible et polices sans empattement et avec métriques anglophones la quasi-totalité du temps).