Espaces fines
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.
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?
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).