Wikipédia:Encodage

(déplacé du bistro le 2003-11-20)

Sur les mailing lists internationales a lieu en ce moment une grande discussion sur la question de l'encodage utilisé sur Wikipédia, et notamment le Wikipdia fr:.
Actuellement Wikipédia:fr utilise le Latin-1, que les navigateurs traitent sans problème, mais qui n'a par exemple pas le œ.
Il est question de convertir l'ensemble des bases, et au moins la fr:, en UTF-8, qui comporte tous les symboles.

Jusque-là, rien que de très technique.

Cependant, ce changement peut poser des problèmes avec les navigateurs ne traitant pas bien l'encodage UTF. Les statistiques rapides (et probablement imprécises) de Brion sur de: montrent que 2% des éditeurs utilisent un navigateur qui poserait problème.
Potentiellement, une édition avec un navigateur à problème peut 'casser' une page, nécessiter de remodifier les caractères spéciaux.

Les différentes solutions mentionnées sur les mailing lists sont:

• interdire les éditions avec un navigateur à problème, et suggérer des remplacements
• convertir à la volée quand on détecte un navigateur à problème
• garder ISO8859-1 qui convient très bien pour la quasi totalité des usages et qui est le charset de base en HTML

Ryo 18 nov 2003 à 19:34 (CET)

J'ajouterai que tout le monde n'a pas nécessairement le choix de son browser (pensez au PC d'emprunt, celui du bureau, ..) et qu'il ne faut pas tenir compte seulement des browsers, mais aussi de la compatibilité avec d'autres outils, par exemple j'utilise courament un mailer qui ne supporte pas du tout UTF-8 mais est parfait en ISO885-1, le copier-coller entre les deux fonctionnera-t'il encore? (réponse: non!); idem avec des projets d'articles écrit sur des fichiers textes en ISO885-1 et ceux qui éditent off-line, leurs outils devront eux aussi être upgradés pour supporté l'UTF-8. -- Looxix

la question de la compatilité avec les autres outils est importante en effet, pour moi aussi. FvdP 18 nov 2003 à 22:16 (CET)

Quels sont les navigateurs problématiques ? Ellisllk 18 nov 2003 à 22:25 (CET)

Les (très) vieux Netscape de la série 4.x, links, lynx et opera <6. À noter que links et lynx affichent correctement les caractères UTF-8. En revanche pour l'édition je n'en suis pas aussi sûr. Med 18 nov 2003 à 22:36 (CET)

Ayant été soumise au problème pendant plus d'un an, je tiens à préciser que les dégâts aux articles ne seront pas "potentiels", ils seront obligatoires, puisque tout accent est détruit par les navigateurs en question. Je peux faire une démo sur méta a tout moment pour les sceptiques. Note : j'ai aussi été traitée de vandale parce que je détruisais les pages la bas :-))) Anthere

Moi je suis à 100% pour la conversion, quitte à interdir l'édition aux navigateurs pouvant éventuellement poser problème. 8859-1 est assez antique comme ça. Voilà une bonne occasion pour s'en débarrasser. Le système actuel pose problème dès qu'on veut utiliser un caractère non latin-1. Il faut aller fouiller les tables unicode pour trouver le caractère et mettre son numéro unicode. Pour Looxix, même emacs supporte l'UTF-8 maintenant donc ça ne devrait pas poser de problème. Linux, Windows et OS X gèrent UTF-8, donc l'édition hors-ligne ne devrait poser aucun problème. Pour les versions antiques des Macs je ne sais pas trop mais il ne doit pas être impossible de trouver un bête éditeur de textes en UTF-8. Pour le navigateur dont on n'a pas le choix : il suffit de télécharger Firebird qui peut être utilisé sans l'installer sur le système (dézippage dans le répertoire utilisateur et zou!). Sinon je ne vois pas pourquoi il y aurait un problème lors des copier-coller. Enfin sous KDE tout du moins il n'y en a pas. Par exemple le wikipédia polonais est en UTF-8 et je n'ai jamais eu aucun problème avec celui-ci. L'UTF-8 c'est le futur et wikipédia aussi. Marrions donc les deux! :) Med 18 nov 2003 à 22:36 (CET)

Quand on a pas le choix de l'editeur il suffit de charger un editeur. Demarche interessante :) Fenkys 18 nov 2003 à 23:04 (CET)

Euh ... je ne suis pas sûr de bien comprendre. Emacs gère l'UTF-8 (et emacs est installé sur tous les unix), notepad gère l'UTF-8 (et notepad est installé sur tous les windows) ... Tout ça pour dire que le problème de l'éditeur n'en est pas un. Med 18 nov 2003 à 23:10 (CET)

Pour tout dire, si ce n'est pas moi qui ai soulevé le lièvre le premier, c'est du moins moi qui ai réveillé le sujet dormant dernièrement dans la liste de diffusion Wikitech. Je suis entièrement de l'avis de Med, avis que j'ai défendu là-bas ; je préfère l'exposer ici : russe, chinoise, japonaise, espérantophone, indienne, slovène, grecque, de nombreuses autres Wikipédias (ainsi que d'autres projets de Wikimédia comme Wiktionary) utilisent déjà utf-8 sans problèmes majeurs. De plus, il existe déjà des problèmes de codage sur Wikipédia avec latin-1 : j'en veux pour preuve la page Comment gérer les conflits de NPOV, qui, dans l'état actuel, utilise des apostrophes courbes codées en brut (il pourrait y avoir aussi un œ). Si quiconque utilisant un navigateur moderne et respectant à la lettre les normes de codage édite cette page (c'est le cas pour moi avec Opera 7.21), les apostrophes seront rempacées par des ?, parce que le logiciel ne devrait pas coder en brut ce caractère, qui n'appartient pas à latin-1. Le cas n'est pas rare et je passe aussi du temps à copie-coller des pages que je veux modifier pour y remplacer les apostrophes et les œ qui seraient mal codées. De même, certains navigateurs remplacent systématiquement les espaces insécables par des espaces normales, ce qui ruine la présentation typographique (ceci est un vieux débat : je ne souligne que le fait qu'il existe déjà des problèmes de codage).

Mais... Le remplacement des apostrophes et des œ par des ? est facilement sauvable : un traitement de texte simplissime peut le faire (sachant qu'il y a tout de même peu de mots en œ, la vérification de chaque occurrence n'est pas une grande difficulté). De même celui des insécables qui, n'apparaissant que devant certains caractères, peuvent être restaurés assez rapidement. Maintenant, imaginons un texte dans lequel tous les caractères étendus sont remplacés par un ? : cela touche principalement éèçàù, l'espace insécable, les apostrophes courbes et tous les autres caractères étendus plus rares mais en très grand nombre dans une page de linguistique, par exemple. Il serait impossible, devant un tel massacre de diacritiques pourtant innocents, de remplacer automatiquement tous les caractères mal codés.

Mais... Il suffit de rétablir la version précédente de la page et de rétablir les changements à la main, ce qui est rarement très long (sauf dans les grandes discussions, là...), chose que je fais souvent pour rétablir des apostrophes, des œ, etc., sachant que rétablir une page dans laquelle tous les caractères étendus sont mal codés n'est pas plus long que si un seul type de caractères l'est. Bref, je suis pour utf-8 mais conscient des nouveaux problèmes qu'il ferait surgir en en éliminant d'anciens.

Bonne soirée, Vincent 18 nov 2003 à 23:29 (CET)

Consciente de ce que vous ne saisissez peut être pas l ampleur de la situation, meme si ce n est que 2% des cas, je vous ai cree deux pages sur meta

Merci de les considerer avec *attention* pour bien comprendre quels seront les avantages et les inconvénients du passage a utf 8.

En voila un m:Lorraine

Et m:Vocabulaire de l'islam

Anthere

Oui, nous sommes d'accord ; je rappelle cependant qu'il est possible de restaurer facilement la version précédente. Le plus casse pieds et de rajouter les modifications, ce qui n'est pas plus rébarbatif que de corriger des apostrophes et des œ ; 2 % de cas à corriger : je ne sais pas si ce n'est ce que l'on a comme navigateurs actuellement problématiques. Vincent 18 nov 2003 à 23:56 (CET)

Bon, voici en gros les options, rajoutez celles qui manquent:

• laisser tel quel
• convertir en utf8, corriger à la main les pbs
• convertir en utf8, faire que le logiciel corrige les pbs (conversion automatique à détection du navigateur)
• convertir en utf8, interdire les navigateur à pb
• conversion par le logiciel avant et après édition, en utilisant les codes &machintruc; ou &#ABCD;. (détails ici).

Ryo 19 nov 2003 à 00:07 (CET)

Une solution technique possible (et à mon avis très praticable): tout le monde peut éditer. Wikipedia devine (ou l'utilisateur déclare en option) le jeu de caractères que l'utilisateur est susceptible d'encoder. Mettons que l'utilisateur est un chinois qui ne supporte pas les "é". Lorsqu'il reçoit sa page, Wikipedia transforme tous les "é" en "é" ou autre équivalent. Lorsqu'il envoie la page éditée, Wikipedia retransforme tous les "é" et autres en les codes Unicode (UTF-8) correspondants. Un petit (?) problème que je vois avec çà, c'est quand le "é" est entouré de <nowiki><-- ;-) -->, y a-t-il d'autres cas similaires ? FvdP 19 nov 2003 à 00:14 (CET)

Ça me paraît un peu compliqué tout ça. Surtout que pour l'instant les chinois sont déjà en utf-8, donc pour eux il n'y a pas de problème. S'ils arrivent à lire les wiki chinois ils peuvent lire le notre. Ce que je propose en revanche c'est que lorsqu'on détecte un navigateur qui ne gère pas l'UTF-8 alors on transforme de la façon suivante:

• les caractères latin-1 sont codés avec les "é" et compagnie.
• les autres caractères sont codés avec leur numéro unicode &#xxxx;

Transformation inverse dans l'autre sens. C'est le plus simple ÀMHA. Et comme ça les autres 98% pourront profiter de tous les avantages de l'UTF-8.

Med 19 nov 2003 à 00:21 (CET)

C'est essentiellement ce que je propose. &eacute; vs &#xxxx est une question de détail. FvdP

Oui, mais ce que je voulais dire est que le Chinois n'aura pas de problème.

J'ai choisi "é" et les chinois comme exemple, c'est tout, en supposant qu'un programme chinois ne sache pas interpréter "é". Les problèmes de mon Chinois hypothétiques et peut-être irréel sont les mêmes que les problèmes très réels d'Anthere. FvdP