Nouvel essai d'envoi de copie suite à discussions sur une autre liste. Certes vous avez sans doute déjà discuté de pas mal de points, mais c'est transmis dans l'état. normalement ce message aurait du passer. Avertissement ce message est long car il contient une suite de messages et en référence d'autres.

Message du 27/10/10 23:50 De : "Nicolas Delvaux" 608631@bugs.launchpad.net A : verdy_p@wanadoo.fr Copie à : Objet : [Bug 608631] Re: Visual tag to represent narrow non-breaking spaces

@verdy_p: please translate your comment in French and mail it to traduc_AT_traduc_DOT_org

We discuss about the remaining problems with NNBSP support on this mailing-list (it's a kind of coordination list for all French translation projects in FOSS).

Here, it is a bug report about Launchpad. And the relative bug is now fixed. (The [nnbsp] tag is not yet available, even in edge, but it should land soon).

ps: as a reminder, I made this report about the current support of NNBSP: http://malaria.perso.sfr.fr/fines/fines.pdf If you observe something different and/or want to improve it, please raise the topic on the aforementioned mailing-list.

-- Visual tag to represent narrow non-breaking spaces https://bugs.launchpad.net/bugs/608631

OK. voici une traduction de mes deux commentaires envoyés à Lauchpad.net sur la nécessité (qui a finalement été acceptée après moults débats...) de non seulement supporter la fine insécable dans les traductions, mais aussi de les rendre visibles dans l'interface pour les traducteurs avec une balise [nnbsp] (ce qui a été fait et sera effectif d'ici peu). L'original (posté en anglais) était dans la liste des messages du bogue lié ci-dessus. Merci Nicolas.

--- [msg #3] (avant résolution du bogue) ---

En fait, la balise à afficher dans une version localisée de l'interface pourrait aussi bien être [fine] si on traduit vers le français. Cela se transcrira bien sûr vers le caractère Unicode NNBSP.

Et le caractère de ''fallback'' (rendu alternatif) utilisé dans les moteur de rendu (texte/police) doit D’ABORD être le caractère THINSP quand il en existe un mappage dans une police (car les polices n'encodent pas elles- même la propriété sécable/insécable, et parce que cette propriété est mise en œuvre en fait dans le moteur de rendu ou de mise en page.)

Autrement, le moteur de rendu ou de mise en page devra établir un fallback en utilisant un avance de la moitié de celle de l'espace standard (SPACE) mappé dans la police (le mappage de THINSP est très fréquent dans les polices depuis longtemps, alors que celui de NNBSP est très peu fréquent et même a été abandonné, par exemple il a été ajouté dans "Times New Roman" très tôt par Microsoft, mais pas dans la police plus récente "Segoe UI" pour Windows 7, considérant que c'était inutile...)

Le mappage vers NBSP (U+00A0) ne sera mis en place que dans des moteurs de rendu non graphiques tels que les émulations de terminal ou consoles ou les programmes qui exporte du texte brut via un encodage non-Unicode des caractères qui ne dispose d'une espace fine (sécbale ou non), car il est plus important de préserver une largeur d'espace quelconque mais aussi de préserver la propriété insécable, même si nombre de terminaux en mode texte brut ignorent totalement les propriétés de sécabilité et ne font aucune rupture de ligne intelligente mais peuvent couper une ligne après n'importe quel caractère même

en

milieu de mot.

concernant GetText, un ''patch'' pourrait être ajouté de façon à ce qu'il retourne des chaînes après conversion vers un encodage cible autre qu'Unicode (mais je ne pense pas qu'il s'agit d'une tâche de

GetText

lui- même, car une telle conversion de l'encodage fait plutôt partie des bibliothèques de transcodage).

Ce n'est pas à getText de modifier l'encodage, et en fait il n'a besoin que de retourner le texte tel qu'il est encodé dans les fichiers sources .po/.pot avant qu'il soit compilé dans une forme binaire efficace. Si GetText traite les fichiers .po/.port, ces fichiers devraient seulement être encodés dans un encodage qui est *compatible* avec le jeu invariant ISO 646 IRV (seulement pour en détecter correctement la syntaxe), afin

de

pouvoir correctment trouver les sauts de lignes, les signes égal, les barres obliques inverses (''backslashes'') et les croisillons qui débutent les lignes de commentaires et les directives signalées juste après ce croisillon avec un caractère de ce sous-jeu limité de l'ASCII.

C'est pourquoi GetText peut être utilisé de façon trnsparente sur les fichiers de resources encodés aussi bien comme fichiers textes Windows ou Unix (CR+LF ou CR seulement), utilisant ASCII ou toute partie

de

l'ISO 8859, ou toute page de code Windows "ANSI" ou "OEM/PC", ou tout codage des normes chinoises GB, ou tout jeu extrait de la norme indienne ISCII. Avec des changements mineurs (utilisant un remappage bijectif 1-à- 1), il peut aussi fonctionner avec des fichiers de ressources encodées avec toute page de code EBCDIC.

Ce que cela signifie c'est que c'est à l'application cliente utilisant ces ressources de savoir avec quel encodage elles ont été encodées. La plupart cependant devraient être encodées avec Unicode et toute application aujourd'hui devrait être capable de transcoder depuis Unicode vers *leur* encodage « naturel » utilisé dans l'application et utilisé historiquement dans leurs fichiers de ressources. Et les mêmes programmes devraient aussi fonctionner sans changement en utilisant au minimum UTF-8 comme leur codage natif, même si cela signifie qu'ils devraient supporter des caractères codés sur des longueurs variables, ou devraient être capable de travailler de façon interne avec UTF-16 (avec des "caractères" codés sur au moins 16 bits).

(Pourquoi les normes C/C++ refusent encore d'honorer cette contrainte, et ne définissent toujours pas des types standards avec une taille minimale de 16 bits pour travailler sans perte avec des unités de code UTF- 16, ou avec un type standard de 21 bits minimum pour travailler avec des unités de code UTF-32, est toujours un mystère pour moi, alors que la nombre d'autres langages ont défini des types de données

avec

des tailles binaires standard, et notablement au moins une taille fixe de 16 bits pour ce qu'ils appellent un "char", traité différement des autres entiers.)

Notez que le séparateurs des milliers est définitivement pas THINSP (car il est sécable), mais aussi NNBSP (alias notre « fine » française).

Si THINSP est encore utilisé sans quelques logiciels, c'est parce que quelques moteurs de rendus ou de mise en page dépendent encore des polices pour mettre en œuvre le caractère NNBSP avec avec un mappage vers quelque glyphe d'espacement, et ces moteurs oublient d'utiliser des "fallbacks" par défaut vers THINSP quand ce dernier est mappé dans les polices (la plupart des polices d'usage général contiennent un mappage pour THINSP, mais toujours pas pour NNBSP dont le support s'est en fait même réduit ! En témoigne ce qu'a fait Microsoft en n'incluant pas NNBSP parmi la liste des caractères que les concepteurs de polices pour Windows devraient inclure dans le mappage de leurs polices ; et je pense que Microsoft à ce sujet a eu raison : la seule différence entre NNBSP et THINSP est l'insécabilité, et cette dernière ne

fait

de toute façon pas partie des propriétés prises en compte par les polices).

En fait le comportement par défaut (la sécabilité) de THINSP était une erreur initialement commise par Unicode dans ses propriétés de caractères. THINSP aurait du être le caractère à utiliser mais Unicode a ajouté des propriétés de sécabilités (qui ne font par partie de la norme ISO 10646 elle-même) en oubliant ce caractère parmi les caractères dotés de l'insécabilité lorsque THINSP a été encodé au début, et les

polices

n'avaient pas non plu à être conçues pour tenir compte de cette propriété (puisque ce n'est pas leur job) y compris pour les caractères explicites de rupture de ligne (comme CR, LF, ou autre FF!) Le caractère NNBSP a été ensuite rejeté plusieurs fois par le groupe de travail international en charge de l'ISO 10646, considérant que THINSP était destiné à jouer ce rôle. Cependant ils ont du se rendre à l'évidence et admettre que THINSP ne pouvait plus être plus changé pour devenir insécable, et ont donc tardivement admis NNBSP (pour ISO 10646, les deux caractères THINSP et NNBSP restent de parfaits synonymes, la différence n'étant visible que dans les propriétés Unicode, celle de sécabilité étant normative uniquement dans Unicode).

Ainsi, NNBSP n'est apparu que très tardivement, bine après que la plupart des polices par défaut conçues pour nos systèmes d'exploitation ont été conçues et inclues dans leur distributions. Mais concernant

les

applications qui traitent des propriétés de ressources, elles ONT bien besoin de la propriété correcte de sécabilité. Dans tous les cas, les fichiers de ressources ne doivent en aucun cas utiliser THINSP mais toujours NNBSP, quel que soit le langage (THINSP lui-même, tel qu'il est encodé sécable, n'a aucune utilité pratique démontrée dans n'importe quelle langues).

Aussi il nous faut mener campagne non pas pour que les polices soient mises à jour pour supporter le mappage de NNBSP (c'est en fait inutile et en fait beaucoup trop compliqué et plus long à obtenir pour corriger des milliers de polices), mais afin que les moteurs de rendu et de mise en page (ils sont peu nombreux et font partie des bibliothèques des systèmes, souvent portables, et incluses aussi dans les navigateurs web) soient mis à jour pour supporter correctement le comportement insécable de NNBSP (et de tous les caractères insécables d'Unicode 5), et qu'ils reflètent aussi l'apparence visuelle en tant que simple espacement (sans même avoir besoin d'un glyphe à dessiner), en utilisant seulement les métriques du caractère THINSP de fallback (quand il est mappé) ou la moitié de l'avance de l'espace standard SPACE (presque toujours présent dans toutes les polices).

Les polices ne devraint alors plus besoin non plus de définir un mappage pour NBSP. Et tout ce dont elles auraient besoin c'est la plupart du temps de ne plus définir que l'esapce ASCII standard afin uniquement d'en définir l'avance métrique. Bref c'est au moteur de rendu ou de mise en page de déduire ces mappages par défaut, même s'il reste possible à certaines polices de définir un mappage qui pourrait être

nécessaire

avec certains designs spécifiques.

--- [msg #37] (après résolution) ---

En réponse au message #35.

Cela n'a aucune importance que le caractère soit incorrectrement rendu ou pas (concernant le support du balisage par [nnbsp] dans l'interface de Launchpad.net et aussi par extension sur TranslateWiki.net

qui

a le même problème). La décision d'inclure ou non le caractère NNBSP fait partie d'une politique ou convention de codage qui devra être revue au sein de chaque projet de traduction (moins en fonction de la langue de ce projet que du support logiciel sous-jascent).

Et quand Bruno Patri a dit que le caractère NNBSP était rendu comme un losange dans les terminaux TTY, cela n'a guère de sens, car cela dépend d'autres facteurs qui dépendent avant tout des conversions de jeux de caractères qui ont lieu soit en seun de l'émulateur de terminal, soit dans son moteur d'affichage, soit encore du côté serveur dans les paramètres de localisation de l'utilisateur connecté à ce serveur, ou des poaramètres de locilisation de ce serveur, ou encore dans l'intégration du terminal su le système (les polices installées, mais surtout comme on l'a vu le moteur de rendu).

La plupart des émulateurs de terminaux utilisés aujoudrd'hui supportent UTF-8 comme l'encodage de choix sur le réseau, comme aussi dans les serveurs d'applications (au moins les distributions Linux ou FreeBSD et, maintenant depuis des années, Sun/Oracle Solaris ou IBM AIX).

Le problème principal n'est pas en fait la présence de NNBSP dans les ressources traduites, qui de toute façon pouvait déjà être introduit dans les ressources, mais dont le manque de différenciation, quand il était saisi, ne permettait de savoir là où il était présent : c'est pour ça qu'on avait demandé un indice visuel dans l'interface de traduction de Launchpad.net (également demandé dans TranslateWiki.net et à demander dans d'autres systèmes similaires).

C'est alors bien à chaque projet de traduction de déterminer quels caractères ils acceptent. La plupart des navigateurs ont maintenant un rendu correct de NNBSP, aussi il n'y a plus de raison de le rejeter (l'affichage correct des espacements est en fait un minimum demandé maintenant pout HTML5 qui décrit plus précisément les propriétés de caractères Unicode que les navigateurs devraient supporter, ce qui comprend

la

reconnaissance de la propriété d'insécabilité et la propriété d'espacement blanc, deux propriétés qui sont définies comem STABLES dans Unicode, et qui sont aussi nécessaires aussi pour mettre en œuvre

IDNA

correctement et sûrement).

Pour les environnements qui ne supportent pas les sorties codées en Unicode et qui dès lors doivent effectuer des conversions de jeux de caractères codés, ce travail sera à réaliser dans les bibliothèques de conversion (telles que libiconv, ICU, ou les API Windows de conversion MBCS/SBCS pour le support des pages de code). Les terminaux ne devraient pas avoir à se préoccuper eux-mêmes de ces caractères, masi la chaîne correcte d'identification du jue de caractère utilisé doit être préservée. APrès tout, les mêmes terminaux auront des problèmes similaires (et en fait plus compliqués et plus sérieux) s'ils ne procèdent pas ainsi pour l'affichage correct du chinois, du russe, de l'hébreu, des écritures indiennes ou du thaï, et ne devraient donc pas avoir à interdire le caractère NNBSP afin d'obtenir un affichage acceptable.

Des polices libres et des moteurs de rendu libres ont disponibles (de même que des équivalents dans les systèmes commerciaux) et devraient être mis à jour pour supporter ensemble ces caractères, même si une police n'a pas nécessairement à supporter NNBSP mais seulement THINSP (y compris dans Windows 7 où par exempel "Segoe UI" n'inclue que THINSP dans sa table de mappage, alors que "Times New Roman" définit depuis longtemps un mappage pour NNBSP qui était fourni déjà dans Windows Vista et dans des services packs pour Windows XP ou pour MS Office : cela n'est plus nécessaire pour Windows 7 qui garantit dans son moteur de rendu système que NNBSP affichera la même glyphe que THINSP quand il est mappé, et peut émuler tous les autres caractères d'espacement et supporter la propriété de sécabilité dans tous les caractères présents au moins dans Unicode 5.0 au moins).

Qt est sans aucun doûte en retard sur ce support, mais je pense que c'est tout bonnement car il ne met pas en œuvre le moteur de rendu du texte lui-même mais dépend encore de vieilles versions de moteurs de rendus liés par des bibliothèques mal identifiées sur les systèmes qu'il supporte et pour lequel il a été contruit ou porté. Cela provoques les différences de traitement qu'on a vu selo le système sur lequel on exécutait une application Qt). Qt sur Windows fonctionne bien maintenant et affiche NNBSP correctement, même si la police "Segoe UI" ne mappe pas ce caractère. Un tel mappage par défaut (fallback) peut aussi

être

réalisé sur les serveurs de polices X11 pour Linux/FreeBSD et autres *nix, même si la bibliothèque du moteur de rendu ne l'implémente pas lui-même (cela ne nécessitera pas nécessairement de mettre à jour les polices elles-mêmes, surtout quand nombre d'entre elles ne sont pas libres ou leurs mise à jour est difficile).

Une mise à jour de XFree86 (ou similaire) pourra résoudre le problème facilement (de telles mises à jour sont maintenant fréquentes pour des raisons de sécurité et cela a été facilité par des services de mise

à

jour système aujourd'hui proposés pour être utilisables par presque tout le monde sans entrer dans les détails techniques ni avoir à installer un compilateur ou recompiler les packages puis les installer ou déboguer ce qui ne marche pas lors de la compilation). Il est de meˆme trsè simple aujourd'hui de mettre à jour son émulateur de terminal (Xterm/telnet et similaires) car ce sont des applications clientes de base qui n'ont que très peu ou pas du tout de dépendance avec le système de base et qui fonctionnent entièrement dans le domaine utilisateur (et non au niveau du noyau, comme cela se fait encore dans Windows pour sa

"console"

qui intègre le rendu et les conversions de jeux de caractères, ainsi que quelques fonctionnalité de gestion de terminal, avec certaines parties du code incluses dans le noyau de démarrage du système de base).

Les seuls environnements restants seront ceux des interfaces de systèmes embarqués avec des capacités de rendu limitées (et souvent pas facile ou presque impossible à mettre à jour). Le besoin de NNBSP

est

suffisamment démontré que l'on devrait demander le support à leur constructeur (pas facile quand on voit que des constructeurs connus comme Philips, Nokia, LG.... ont encore du mal à supporter déjà tous

nos

caractères acentués, par exemple "ë / ï / ö / ô" dans les sous-titrages de télévision, dans les noms de chaînes TV HD, dans les jeux proposés pour les SMS...) afin qu'il l'intègre à leur firmwares (on voit là

encore

le problème des systèmes propriétaires, y compris ceux construits sur des systèmes libres mais dont ils n'ont rien fait pour que ces systèmes soient facilement mis à jour par des tiers et qui n'assurent aucun support réel pour ce qu'ils considèrent comme mineur, tout en ne mettant pas non plus en place un réel support en ligne pour leurs utilisateurs.

Mais rien ne se passera chez ces constructeurs de systèmes embarqués s'il n'y a pas d'incitation externe poussant leurs auteurs à prendre en charge la fonctionnalité. Le mieux qu'on puisse faire c'est de documenter les usages qui sont déjà faits, montrer là où ça marche déjà et promouvoir les systèmes qui fonctionnent avec la fonctionnalité demandée afin qu'elle soit de plus en plus utilisée et que son absence soit reconnue comme une réelle anomalie. Grace aux corrections qu'on va demander et obtenir, ils sauront que ce qui manque est réellement demandé et ce qui est attendu par les utilisateurs: s'ils ont été capables d'adapter leurs applications et systèmes pour le chinois simplifié ou traditionnel, ou le coréen, le japonais, l'hébreu ou même simplement le russe ou le bulgare, ils ne devraient plus avoir de difficulté à gérer correctement

un

simple espacement (et tant qu'à faire tous les espacements d'Unicode 5.0 au moins) et la propriété d'insécabilité de tous les caractères Unicode 5 qui en disposent, ce simple espacement insécable étant en fait nécessaire et utilisé depuis des siècles dans des langues truès utilisées comme le français, l'espagnol ou le russe.

quelqu'un doit commencer le travail (évitons la question de la poule et de l'œuf, ou même celle de la charrue avant les bœufs). Les autres suivront rapidement et de plus en plus vite ensuite. On ne

progressera

jamais si chacun commence par regarder ce que les autres n'ont pas fait (et en fait les premiers pas les plus importants ont été largement faits maintenant par les 5 navigateurs majeurs du marché et dans Windows, ainsi que dans quelques environnement Linux).

Il n'est donc pas raisonnable de bloquer le caractère dans Launchpad (et tant pis s'il reste quelques applications non remises à jour qui n'affichent pas le caractère correctement ou au moins d'une façon lisible et acceptable). Il est même sans doûte souhaitable de rendre cette anomalie de manque de support visible d'une façon ou d'une autre afin de pousser les auteurs de ces environnements à proposer des

corrections

mais aussi pousser les utilisateurs les plus résistants à mettre à jour leurs systèmes: même s'il y a des raisons légitimes pour eux de ne pas mettre à jour, cela ne tiendra pas dans le cas des nouvelles

traductions

qu'on proposera qui implique de toute façon que ces mêmes utilisateurs "rétifs" aux mises à jour ont déjà installé une version récente d'un logiciel (et donc effectuent des mises à jour).

Alors qu'en fait cette décision de bloquer (pour un temps seulement) des caractères ne doit dépendre que de chaque projet de traduction et de la façon dont le projet est réutilisé. On doit mesurer l'impact bénéfices/risques, sachant que les risques en question ne sont pas ceux (légitimement bloquants) liés à la sécurité des systèmes, et en tout cas les bénéfices en terme d'interopérabilité ou d'accessibilité et lisibilité seront supérieurs. La plupart des projets accepteront ce caractère sans problème pour la très grande majorité des emplois qui en sont faits (les autres attendront un peu avant d'appliquer une mise à jour, le temsp que eux aussi s'adaptenr et finissent eux aussi à accepter un caractère bien utile, et que chacun convienne que finalement on conçoit mal comment on avait pu résister à cette évolution).

La plupart de ces projets pourront créer et intégrer leur propre petit "patch" sans grande difficulté (soit en mettant à jour les bibliothèques dépendantes, ou en ajoutant des exceptions dans leurs propre code pour supporter tous les espacements d'Unicode 5, ou en intégrant dans leur distribution des polices compatibles avec un mappage explicite du caractère, ou en changeant leurs propres convertisseurs intégrés de

jeux

de caractères (libiconv par exemple a le support nécessaire, et la mise à jour ne nécessite que l'installation ou le remplacement d'un unique fichier sur le système, ou au pire dans le répertoire de l'application si l'accès au système est limité et nécessite une installation "parallèle" spécifique à l'application, comme cela se fait maintenant couramment sur Windows qui permet à une même bibliothèque d'être installée dans plusieurs versions selon les applications qui en ont besoin ; dans les faits, cela se produit déjà avec les mises à jour des navigateurs Internet, qui constituent de plus en plus une brique de base de tous les systèmes d'exploitation destinée à construire de plus en plus nombreuses applications).

Il faut aussi reconnaître que maintenant plus de la moitié du web utilise Unicode et que les anciens jeux de caractères 8 bits (y compris les jeux multipages comme ceux des normes GB chinoises) sont maintenant dans une phase de décroissance et d'abandon rapide (nombre de sites ont converti jusque y compris leurs bases de données). Le point déclenchant de cette évolution a été la décision de l'IETF de rendre le support d'UTF-8 obligatoire dans toutes les nouvelles normes transportant du texte, et en même temps de nombreuses corrections apportées dans les protocoles existants afin d'identifier correctement et supporter Unicode. certains protocoles demandent des changements très complexes (cas de l'IDNA et du protocole DNS en général), mais cela ne concerne qu'une toute petite partie des données textuelles du web, et de plus en plus une partie de moins en moins visible par nombre d'utilisateurs (merci aux moteurs de recherche et à l'intégration dans les navigateurs de moyens fiable d'identifier correctement des noms de domaine "sûrs").

Les environnements de bureau X11 ont aussi fait de gros progrès pour supporter de nombreuses langues et écritures. Plus de 60% des emails échangés sont maintenant codés en Unicode, tandis que le

contenu

du web commence à être de plus en plus interactif avec une part sous la forme de contenus vidéo qui a explosé et représente déjà le tiers des volumes échangés (Un rapport publié par Cisco récemment en semtembre indique déjà que la consommation de bande passante réalisée aujourd'hui par seulement une vingtaine de "foyers moyens" représente autant de volume que la totalité des échanges sur Internet dans le monde entier en 1995 ! Si vous voulez je retrouverai la référence) On voit donc que face à cette évolution, il a fallu mettre à jour la quasi totalité des systèmes pour accéder à ces contenus, et qu'il n'y a en fait que très peu de résistance au changement. Mettre à jour n'est plus un problème mais une nécessité.

Et toutes ces mises à jour sont maintenant entièrement dépendantes, au plan technique, du support correct d'Unicode, dont le support (au minimum UTF-8 pour les protocoles Internet de l'IETF, et par la suite aussi dans les autres languages et systèmes utilisés pour s'y connecter) a été rendu obligatoire. Toutes ces technologies dont l'usage explose (et la part énorme et explosive prise par la Chine dans ces échanges) ne viennent qu'affirmer qu'on ne doit plus se limiter aux anciens jeux ASCII ou ISO 8859. Les caractères NNBSP et THINSP sont une partie microscopique des changements nécessaires. Il n'y a pas lieu de les refuser.

Conclusion : avançons et ne nous bloquons plus là-dessus. On n'aura même pas besoin de réellement faire compagne pour que les utilisateurs mettent à jour leurs systèmes, puisqu'ils le font déjà

massivement

et personne ne contestera ce support, mais de plus en plus nombreux seront ceux qui incendieront les équipes de supports de produits qui refusent de telles changements mineurs et aujourd'hui faciles à intégrer.

--- [Conclusion]

D'autres messages sont à consulter sur la page de commentaires du bogue sur "Visual tag to represent narrow non-breaking spaces" https://bugs.launchpad.net/bugs/608631

Je n'ai pas traduit la totalité des échanges (en anglais), juste deux de mes messages avec quelques insertions ici (en gardant l'esprit général). L'important est maitenant pour beaucoup de savoir que Launchpad.net supporte officiellement NNBSP en y apportant une facilité destinée aux traducteurs afin qu'ils puissent facilement en identifier l'usage (et que d'autres vont suivre...)

Parmi les points évoqués par Nicolas Delvaux dans son document référencé dans sa réponse #38, figure son très intéressant rapport:

http://malaria.perso.sfr.fr/fines/fines.pdf

Cependant il semble avoir oublié une autre cause de certaines des irrégularités qu'il mentionne :

• le support des conversions de jeux de caractères (libiconv et similaire) : comment ils traitent un caractère manquant dans un jeu de caractères codés non Unicode.
• ou leur identification dans les protocoles de transport quand ce n'est pas Unicode (ce problème n'est pas spécifique à NNBSP mais est toujours le même que celui qui se produit depuis longtemps pour

afficher

correctement les caractères NON-ASCII, y compris nos lettres accentuées, ou les autres écritures non latines). Il ne devrait plus être nécessaire d'utiliser autre chose que l'UTF-8 pour le stockage ou le transport, même pour des applications non-web et des systèmes "non connectés". Et la plupart des systèmes utilisent UTF-16 pour leurs traitements interne du texte (ECMAScript, DOM, Java, ...) à l'exception encore de C/C++ (qu'attend encore l'ANSI pour établir un type standard fiable pour les UTF standards ?), et PHP/MediaWiki (dont les situations sont encore ambiguës pour identifier les jeux de caractères utilisés).

Philippe.