Depuis quelques temps, je tombe de plus en plus souvent sur les travaux du W3C concernant l'internationalisation des documents (i18n).

Bien qu'ayant lu quelques pages sur le site du Consortium, dont les très éclairantes questions fréquentes, je n'arrive pas encore à cerner clairement les enjeux reliés à ce domaine. Que doit-on faire pour respecter les normes d'i18n ? Comment peut-on mesurer le degré d'efficacité de nos sites Web face aux autres cultures du monde ? Quels sont les requis à observer pour être réellement "international" ? Autant de questions auxquelles je ne trouve pas encore de réponses satisfaisantes.

Je me demande s'il existe une ressource dédiée au sujet qui aurait fait le travail de vulgarisation de ces aspects, avec des didacticiels d'introduction, un peu à la manière d'OpenWeb ou d'Alsacréations avec les CSS, le XHTML et l'accessibilité. Vous en connaissez, vous ? On parle beaucoup de CSS, de XHTML et de XML lorsque l'on parle de normes, mais on aborde pratiquement jamais les autres, comme justement i18n ou même HTTP. Il est peut-être temps d'élargir nos horizons en les considérant également...

Jamais entendu parler...
Curieux de nature, j'aimerais comme toi tomber sur une bonne ressource francophone maintenant.

Bonjour,

Je n'avais jamais entendu parler... mais première observation : pourquoi donc une page qui traite de l'internationalisation n'offre pas sa traduction en plusieurs langues ?
Je vais approfondir cette question pour me faire une opinion, mais du coup, j'ai un doute, s'agit-il d'internationalisation ou d'anglicisation ?

Dino

Je n'ai pas la moindre idée de ce que représente cette norme :"i18n"...

Désolé de ne pouvoir t'aider.

++

au vu de ceci il s'agit plutôt de concevoir un produit interactif (site, logiciel, script, etc.) de façon à isoler les élèments de langage dans une matrice dont il ne reste plus qu'à faire traduire les élèments dans autant de langage que possible. x matrice -> x langage dans lequel le produit est visible. l'interactivité mentionnée plus haut servant alors à l'utilisateur pour choisir son langage à l'initialisation du produit (page d'accueil, etc.).

maintenant je ne pense pas non plus qu'il s'agisse d'appauvrir les phrases utilisées sur les sites pour en faire des "expressions standards" traductibles comme des caractères ASCII, mais on ne sait jamais...

Oui, sauf que la ressource sur laquelle tu pointes concerne le développement logiciel... j'ai l'impression qu'il en va tout autrement pour le développement Web. Est-ce que je me trompe ?

je ne pense pas que i18n soit une norme, c'est simplement un sigle pour dire internationalisation (i puis 18 lettre puis n).

Dinostrate => une petite remarque, ceux qui parle de la guerre doivent la faire ? ceux qui parle du rouge doivent écrire en rouge ? remarque bis : certaines pages sont en français.

Les travaux du w3c regroupe les "bonnes pratiques".

L'enjeux est d'avoir des pages qui s'affichent correctement quelque soit la langue utilisée.

Pour cela il faut choisir un encodage pour les pages (qui peut être différenet en fonction de la langue) mais surtout pas mélanger plusieurs encodages sur la même page. Ensuite il faut indiquer cet encodage au navigateur, dans le header de la page et à l'aide des différente balises, de même pour le nom de la langue elle même.

Ensuite prevoir la traduction des pages, donc en général regrouper tout les libellés dans un fichier unique.

Il y a également beaucoup de problème de présentation en particulier avec les caractères "exotiques" comme le chinois, ou les langues qui s'ecrivent de droite à gauche.

On peut aussi citer les manières pour fournir la page dans la langue approprié, en utilisant la détection de la langue du navigateur, demander à l'utilisateur de faire son choix, pour garder ce choix d'une page à l'autre utiliser les sessions ou les cookies...

Voila les questions principales qui se posent lorsqu'on veut internationaliser un site web, plus pleins d'autres détails que tente de regrouper le w3c.

Bien vu, Fight !

En ajoutant la question des contenu de pages équivalents ou non selon la langue, c'est en tout cas ce que, moi aussi, j'ai tiré des docs du W3C.

Bonjour,

J'ai coché "Jamais entendu parler" ce qui est presque vrai... j'en ai entendu parler pour la première fois en lisant ton billet sur Cybercodeur.

J'ai juste parcouru et je ne sais pas si ceci répond à ton attente : Créez votre site Web multilingue.

Idem

Dans le meme ordre d'idee, il y a aussi le sigle "m17n" pour : "multilingualization"

S'il n'y avait pas ces contention de designation, si le mot "internationalization" devait lui-meme etre traduit dans chaque langue, patois et dialecte, on ne se comprendrait plus...

Pour le developpement multilingue proprement dit, au-dela de l'encodage des pages et de quelques considerations superficielles, je ne pense pas qu'on puisse etablir des standards reellemment pratiques pour vraiment "internationaliser" un site. Chacun sa technique. En fonction du probleme a resoudre et de ses choix techniques.
On peut par exemple gerer les langues via XML, via des bases de donnees (parfois on decouvre une table "i18n"), des fichiers, regrouper les traduction par theme, par langue, etc...

Si mes souvenirs sont bons, le concept d'i18n est (tres) longuement aborde sur les mailing-list de Spip pour les differentes localisations. Mais chaque produit qui se veut international (phpbb, ipb, et n'importe quel produit ou site web) doit a un moment donne se pencher sur sa strategie de gestion de langue. Certaines sont mauvaises (ipb) d'autres sont plus ou moins satisfaisantes

À la lumière de vos réponses, je dois quand même conclure que personne ne peut parler de i18n comme l'on parlerait de HTML ou de CSS... Si on devait rédiger l'équivalent d'un article sur la question, afin de cerner le sujetour un lecteur néophyte, on parlerait de quoi au juste ?

Bonjour,

Je pense qu'il ne faut pas parler d'internationalisation à priori en ce domaine, c'est peut être pour cette raison que j'ai vu un peu rouge dans un premier temps, et peut-être bien à tort..

Comme définition "vulgarisée", je proposerais :

Norme destinée à faciliter la présentation d'une page en fonction des caractéristiques propres à chaque culture et à chaque langue utilisée (difficulté sémantique, niveau d'exigence calligraphique, etc.)

Tout en laissant à chaque culture sa liberté d'expression, Il doit résulter de cette normalisation une meilleure prise en charge par les moteurs, traducteurs automatiques, etc. ce qui ne peut que faciliter une évolution vers une certaine internationalisation.

En fait, le projet me semble énorme....

Dino

En fait, ce que j'essaie de clarifier dans ma tête pour l'instant, ce serait la différence entre internationnalisation et multilinguisme d'un site Web. La différence est expliquée ici ( http://www.w3.org/International/questions/...ltilingual.html ), mais il reste des trucs pas clair dans mon esprit.

Par exemple, le fait qu'un site soit en français, en anglais, en espagnol et en allemand relève du multi-linguisme, mais si je voulais le traduire en arabe, il faudrait également que le contenu soit inversé de droite à gauche puisque ceux-ci le lisent "à l'envers" de nous occidentaux. Est-ce à ce moment que l'on bascule vers l'internationalisation ? A priori, je croirais que oui...

Bon, mon cher Denis, je crois que sur ce coup, on est en plein dans la philo, et ça, ça me branche un max
Je crois que tu as cité un mauvais exemple... la direction du language (écrit, bien sur) ce n'est pas un problème, en effet, le language oral est toujours dans le même sens
Ce n'est pas neutre ce que j'écris...
L'écrit n'est qu'une transcription de l'oral, et le reste suit, en fonction des conventions et des coutumes...

Je devrais donc dire : au commencement, était l'oral.... simple, dont la chronologie était facile à appréhender...
Ensuite, est venu l'écrit, un stade beaucoup plus évolué et bien plus difficile à maîtriser... avec l'écrit, nous avons un commencent des "flashbacks" et autres artifices, que le cinéma s'empressera d'utiliser ensuite...
Tout cela pour dire quoi, en définitive ?

Tout cela pour dire qu'au bout du compte, selon moi, l'internationalisation n'existe pas, et qu'il n'y a que multilinguisme.... et interprétation de ce multilinguisme.... et transcription dans la langue appropriée au "récepteur".

J'attends de voir venir un interprêteur de culture .....

Désolé de dériver un peu par rapport aux techniques du ouèbbe, mais de temps en temps, il faut bien s'interroger sur quelques principes fondamentaux...

Mais, un site ouèbbe, c'est aussi la vie quelque part...

Dino

Bien que le débat de philo me tente, j'enfoncerai mon chapeau de modérateur et j'y résisterai. ^_^

N'en demeure pas moins que d'obtenir du texte s'affichant de droite à gauche, c'est pas mal plus que de la traduction non ?

Si je ne m'abuse, l'internationalisation fait partie des bonnes pratiques du Web. Elle me semble consister en un souci de transcender les conditionnements culturels, géographiques et langagiers pour faire passer son message et tout mettre en oeuvre pour que ce dernier soit compris et bien compris.

En principe, toute symbolisation ou schématisation susceptible d'être mal comprise devrait être concernée par elle.

En amont, l'internationalisation consiste à générer (ou corriger) du contenu en prêtant une attention particulière à des trucs comme :

• l'usage symbolique des nombres, des couleurs, des plantes, des animaux ou des éléments naturels comme l'eau, le feu, etc. ;
• les symboles d'unité monétaire ;
• les formats d'heure et de date ;
• les métaphores et expressions issues du terroir, ainsi que les néologismes, régionalisme, tournures de phrases et autres manières particulières de s'exprimer ;
• etc.

En aval, l'internationalisation profite à ceux à qui on s'adresse en leur permettant de comprendre ce qu'on leur raconte sans les obliger à un effort de recherche pour y arriver.

On comprend dès lors un peu mieux en quoi les problèmes liés à l'internationalisation se distinguent des problèmes qu'on rencontre à traduire un texte ou à en offrir une version en plusieurs langues.

Bonjour Paginus et bienvenue sur le Hub

Si je comprends bien, ta définition rejoint celle d'un interprêteur de culture dont j'ai parlé plus haut.... là, je suis d'accord. Mais c'est vraiment très difficile... après tout, pourquoi pas ?
Pour les "formats d'heure", les symboles, l'expression graphique, la codification parait abordable, et selon moi, tout cela peut être assimilé au langage.

Par contre, en ce qui concerne

c'est autre chose... et là, je suis d'accord pour dire qu'il s'agit d'internationalisation... car ici, on dépasse de beaucoup le langage...

Bon, je ne voudrais pas devenir un "puriste" des définitions... mais le problème, c'est que les définitions sont nécessaires et doivent être aussi claires que possible pour que tout le monde puisse se comprendre, et aussi bien sur, pour enseigner.

Dino

D'accord avec l'idée que les définitions doivent être aussi claires que possible. Mais, il y a un long chemin entre le confus et le distinct. Aussi est-ce pourquoi je ne rechigne pas du tout à ce que mes tentatives soient discutées. Bien au contraire, j'y vois une occasion de les retravailler et de les polir.

Bref, j'ai commencé à éclaircir les choses, mais je ne prétends pas être arrivé au bout du chemin.

Cela dit, je m'explique un peu plus sur les parties que tu ne m'accordais pas : les formats d'heure et de date, et les symboles d'unités monétaires.

Si quelqu'un écrit : "Last update: january 1st 2004" et qu'il s'agit de traduire de l'anglais au français, on écrira : « Dernière mise à jour le premier janvier 2004. » Les difficultés consistaient seulement à passer d'un idiome à l'autre et de respecter les conventions typographiques qui s'y rattachent.

Mais si je suis en train d'internationaliser un site où se trouve : « À jour le 02-03-04 », je dois me demander si le format de date affiché là est le format international où on a les années, le mois, et le jour, le format français, où on a le jour, le mois et l'année, ou le format américain où on a plutôt le mois, le jour et l'année. Car il y a toute une différence entre le 4 mars 2002, le 2 mars 2004 et le 3 février 2004.

Cette première difficulté résolue, je devrai me demander comment afficher cette information de façon à lever l'ambiguïté. De façon donc, à être aussi bien compris des Belges que des franco-canadiens, des Suisses ou des Français. Et là, mon souci n'est pas de traduire, mais bel et bien d'internationaliser.

Le processus est semblable avec les symboles d'unités monétaires. Enfin, certains d'entre eux, pour être précis. Car les signes ¥ et £, par exemple, réfèrent respectivement au Yen et à la livre sterling, sans qu'on ait à se demander lesquels. Mais il n'en est plus de même si j'emploie le signe $. Car les dollars américains et canadiens, pour ne parler que de ceux-là, ne sont pas du tout les mêmes devises.

Écrire 50 $ sur l'étiquette d'un vêtement dans un magasin près de chez-moi ne pose aucun problème, car je suis au Québec et tous ceux qui y vivent savent que les prix sont affichés en dollars canadiens. Mais si le même commerçant annonce le même article sur le Web, il dois préciser la devise dans laquelle ses prix sont exprimés pour éviter toute confusion. Et là, bien qu'il n'ait encore rien traduit en italien ou en espagnol, il fait de l'internationalisation.

Quant à l'heure, la chose m'est arrivée récemment. Je joue aux échecs par correspondance avec un Nantais auquel le serveur de courriel joue parfois des tours. N'ayant pas reçu mon dernier coup, il me renvoie le sien pensant que je pouvais ne pas l'avoir reçu non plus. Pour lui signifier que je l'avais envoyé dans les délais convenus, je dois lui indiquer l'heure où mon courriel lui a été envoyé. Si j'écris : « 10... Cc6, posté hier à 8h37 » et que le courriel lui parvient huit jours plus tard, « hier » ne veut plus rien dire. Et retard ou pas, la question se posera de savoir s'il s'agit bien de 8h37 ou de 20h37. Pour lever toute ambiguïté, j'ai écris : « 10... Cc6, posté le matin du 3 juin à 8h37+5GMT ». Avec le fuseau horaire de surcroît, ça ne pouvait pas être plus international.

Je veux reprendre l'exemple du format de l'heure parce qu'il illustre bien ce que j'essaie de déterminer avec tout ceci. Permettez-moi donc de revenir à la charge avec les notions d'internationnalisation et de multi-linguisme, afin d'essayer encore une fois, de les différencier. Nous convenons qu'il existe un format international et un format local. Si internationalement nous sommes le 04-06-05, j'aurais autant raison de dire qu'aujourd'hui, nous sommes le 05-06-04 puisque je réside au Québec. Dans les deux cas, nous parlons du 5 juin 2004. Normand a bien illustré le propos.

Maintenant, je vous exprime ce qui me semble être la différence entre les deux (internationalisation et multi-linguisme). À vous de me dire si vous me croyez hors du coup. ^_^

À mon sens, le multi-linguisme, ce serait justement de "traduire" le format de l'heure en fonction de la langue et afficher, grâce à une moulinette en backend, le bon format en fonction de la localisation del 'utilisateur (peut-être en se référant à son fuseau horaire et sa localisation géographique).

L'internationnalisation, ce serait plutôt d'afficher pour tout le monde le format universel et l'expliciter dans une page dédiée à l'internationalisation du site (à l'instar d'une politique d'accessibilité par exemple).

Alors, je suis dans les choux ? ^_^

Ce qwui me fais penser... En bon Québécois, j'aurais dit, "dans le champ"... Pour me faire comprendre dans l'ensemble de la francophonie, je dis "dans les choux", puisque c'est calqué du Français international, donc le plus universellement reconnu. C'est pas justement un peu ça, l'internationnalisation ?

En ce sens, comment espérer en tirer une forme de norme, dûment décrite comme par exemple, XHTML ? Dans un tel contexte, ce ne seraient que des bonnes pratiques, au même tire que l'ergonomie et l'utilisabilité...

Ca me fait penser aux étiquettes "A concommer de préférence avant"...
De temps en temps, ils emploient le format suédois (bah, oui, je suis en Suède donc c'est a priori normal) et de temps en temps le format défini dans les standards...

Pour en revenir aux dates, il existe une norme ISO.



Source :
http://www.ic.gc.ca/strategis_client_servi...39?OpenDocument

François

Denis,

Ce dont tu parles mérite considération, mais me semble relever davantage d'un autre concept que ceux d'internationalisation ou de multilinguisme.

Je ne tiens pas à rester au ras des pâquerettes, mais l'intellect ne peut se nourrir que de ce que les sens lui apportent. Aussi est-ce pourquoi je partirai d'un exemple pour illustrer mon propos.

Un humoriste québécois rédige le texte de son nouveau spectacle. Comme ce spectacle sera présenté au public francophone du Québec, il n'est pas question de multilinguisme, d'internationalisation ou de trucs du genre. Il écrit pour son public et il le fera en tenant compte des conditionnements culturels qui lui sont propres. En fait, étant de la même culture que ce dernier, il n'aura même pas à se soucier de ce genre de considération.

Son spectacle ayant connu un franc succès, vient le temps des tournées en France, en Belgique et en Suisse. Toujours en français, bien sûr. Est-il besoin de dire qu'il faudra retoucher au texte? Et comme il ne s'agira pas de passer d'un idiome à un autre, on ne peut pas parler de traduction sans verser dans l'abus de langage. Le mot le plus approprié pour nommer l'effort de réécriture à fournir me semble être celui d'adaptation. S'il veut être compris et toucher les cordes sensibles des publics francophones hors Québec, notre humoriste devra donc adapter son texte. Et il devra le faire spécifiquement pour chacun des pays où il ira.

Ce dont tu parles me semble relever du même genre d'effort.

Cela dit, j'essaie d'articuler tout ça de nouveau pour en arriver à un tableau d'ensemble.

Un site présente un même contenu en plusieurs langues? On parle de multilinguisme. On remplace ce qui est affaire de conventions et de conditionnements culturels locaux par quelque chose d'universellement compris? On internationalise. On fait effort pour s'adresser à chaque public cible en adoptant le système référentiel qui lui est propre? On fait, au contraire, de l'adaptation.

Je ne sais si tout ça est concluant, mais il me semble que les choses se précisent peu à peu. N'est-ce pas aussi ton avis?

Oui, forcément.

Mais une nouvelle question me vient à l'esprit... Dans une perspective d'internationalisation (mais aussi d'accessibilité et d'interopérabilité), ne devrions-nous pas tous utiliser Unicode ?

Me revoilou...

Bon, le truc essentiel, c'est d'avoir une définition claire au départ.... mais pour le moment, on est encore un peu dans le flou...

Laurent, c'est bien parce que je pense que tu as raison dans ce que je cite que je n'ai considéré que pour l'instant, l'effort consenti était plutot multilinguiste....

Les considérations de paginus sont quand même tout à fait intéressantes et après une première lecture, il m'a presque convaincu, donc, je vais procéder à une deuxième lecture Après tout, il suffit de se mettre d'accord sur des conventions...

Je vais m'absenter du hub et d'internet en général pendant 4 à 5 jours... d'ici là, peut être aurez vous trouvé une définition satisfaisante....

a+
Dino

Bon allez, je me lance dans mon premier billet avec des vrais morceaux d'arguments dedans.

Unicode c'est quoi ?
Unicode est la norme qui permet d'écrire tous les langages avec un support informatique. Le but d'Unicode est donc de référencer toutes les écritures, puis de proposer des méthodes pour les stocker sur un ordinateur.

Le but en soit d'Unicode est donc clair, trouver un format de stockage qui permet à tous les caractères du monde d'être écrits, ceci en total contradiction avec l'ASCII qui ne permet d'écrire que les caractères américains.

Unicode devrait-il être utilisé ?
Oui, il est trop souvent nécessaire de supporter plusieurs langages internationaux, notamment dans le cadre d'un outil de publication massivement international (forum de l'ONU), ou dans le cas d'un logiciel massivement international (système d'exploitation).

Unicode devrait-il être utilisé tout le temps ?
Là c'est plus complexe. D'un côté, on peut trouver ceux qui défendent Unicode en disant que l'intéropérabilité est une doctrine qu'il faut toujours suivre quelqu'en soit le prix et qu'Unicode résout enfin tous les problèmes d'incompatibilité des fichiers en mode texte.

De l'autre, on trouve les gens qui décrient les inconvénients d'Unicode. En effet, être capable de stocker tous les caractères de la Terre implique un coùt en terme de place ou de calcul (ou les deux, bien souvent les deux).

Unicode aujourd'hui ?
Il existe aujourd'hui le système des charsets, chacun permettant d'écrire dans une langue précise pour un moindre coùt (1 octet par caractère). Ceux-ci sont donc majoritairement utilisés sur le web aujourd'hui, même pour des langues très exotiques comme le japonais ou le chinois.

Unicode est « réservé » de part sa soit-disant lourdeur aux applications possédant plus de ressources, bien souvent les applications locales d'un ordinateur.

Mon avis
Mon expérience dans le domaine tent à me faire penser que l'idée des charsets, à la base fort intéressante, n'est finalement pas si bonne. En effet, dans un soucis d'économie de la ressource, il a fallu augmenter la complexité des données (devoir spécifier un charset) tout en conservant une compatibilité ASCII.

Cette compatibilité est pour moi une erreur, car bon nombre de gens confondent -- et c'est normal -- l'ASCII avec ces versions améliorées que sont les charsets.

Si l'on prend par exemple les protocoles en mode texte d'internet aujourd'hui (ftp, http, smtp), beaucoup n'ont pas cette notion de charset, et s'ils l'ont, beaucoup de clients ne songent pas à l'implémenter. Pourquoi ? Parce que cela « devrait fonctionner tout de suite » sans avoir à ajouter une information supplémentaire (le charset).

Or l'erreur la plus souvent et la plus rapidement commise est de croire en une compatibilité ASCII et une utilisation de caractères supplémentaires sans ajout d'informations supplémentaires, les applications ayant fait l'erreur de toujours disposer d'un charset par défaut, sans en avertir l'utilisateur.

Cette erreur n'aurait selon moi pas été commise si Unicode était devenu la norme de référence tout de suite, sans passer par des « bidouilles » faites sans un soucis d'intéropérabilité, pleins de charsets que les gens ne comprennent pas et ne savent pas changer.

Il faudrait une seule norme, comme à la bonne vieille époque de l'ASCII, une norme que tout le monde utiliserait sans se soucier du reste, et tout fonctionnerait.

Alors maintenant c'est décidé, je dis non au charsets, c'est mauvais pour mes fichiers. Avant ils étaient ternes et secs, maintenant avec Unicode et tous ses codages (UTF-8, UCS-2), mes fichiers sont soyeux, lisses et brillants.

Unicode c'est bon, mangez-en.

Bonjour,

Merci pour cette explication détaillée anubis :up:


Tu nous donnes la recette ?

UTF-8 semble de plus en plus souvent utilisé, c'est le cas de Dmoz par exemple.
Pourquoi ce type de caractère n'est-il pas toujours automatiquement reconnu par FireFox (j'imagine qu'il en est de même avec d'autres navigateurs) ?
Erreur dans le code ?

• Un bon éditeur capable d'enregistrer en UTF-8
  
  
  
• Une pincée de PHP pour modifier les en-têtes
  
  
  
• Une petite balise <meta> si votre épicier n'a pas de PHP

UTF-8 est tout simplement loin d'être l'encodage par défaut. Pour les pages HTML par exemple, Firefox choisira automaitquement un charset iso-8859-1 pour une page web ne le spécifiant pas. Il se trouve que beaucoup de pages web utilise un encodage UTF-8 (parce que l'éditeur de leur auteur l'enregistre de cette manière) mais ne le spécifie pas, soit dans une leur en-tête HTTP, soit dans une balise <meta>.

Ce que je peux dire à la suite du développement de mon wiki , c'est que l'UTF-8 est bien géré par tous les navigateurs modernes (même IE6) à partir du moment où il est correctement déclaré.

Heureusement, les navigateurs choisissent bien souvent l'encodage UTF-8 pour les documents XML, mais je ne pense pas que ce choix soit une généralité.

Denis, toujours pas convaincu par Unicode ?
On peut s'en passer, mais ça demande plus de boulot. En plus de changer la langue, de changer les préférences d'affichage de type monnaie/date/nombres, il te faudra aussi changer de charset. Une application peut tout à fait gérer ça en interne mais ça demande plus de boulot et c'est la meilleure manière de se planter.
Je peux te dire qu'ici on cherche à implémenter une interface Coréenne sur une appli et une base de données toutes les deux en ISO-8859-1 au départ ... ben c'est pas gagné.

(message perso: d'ailleurs j'en profite pour te signaler que ton fil RSS passe mal chez moi, justement à cause d'un problème de déclaration de charset)



Je rajouterai même que pour les documents envoyés en HTTP avec un type mime en text/* le codage (pas encodage, s'il vous plait) est implicitement du ISO-8859-1 (c'est définit par la norme). Firefox a donc raison de le prendre par défaut. (j'en veux d'ailleurs au validateur W3C qui prend de l'UTF8 par défaut quand rien n'est déclaré).



Si je ne me trompe pas c'est là aussi imposé par les specs : un document XML sans déclaration de codage est un document UTF-8.
(pour qu'il soit sans codage il faut donc qu'il ne soit pas envoyé en text/* sinon le codage est considéré comme déclaré par HTTP)



Globalement, j'ai vu des navigateurs ne pas accepter ISO-8859-15 (le même que par défaut mais avec l'euro et quelques autres caractères en plus) ou ne pas accepter cp1252 (la version proprio Microsoft Windows qui diffère sur les guillemets typo et quelques autres machins) ... mais globalement même les très vieux supportent l'UTF-8. Les seuls chez qui ça ne passent pas ne supportent vaiment que ISO-8859-1 (donc pas d'internationalisation) et ressemblent généralement plus à des scripts qu'autre chose.


Le surcout en taille de fichier est largement négligeable pour l'essentiel des ressources. Surtout si c'est contrebalancé par la pérénité et l'évolutivité.

Le seul défaut se situe au niveau de quelques débats entre les chinois et coréens (entre autres) : ils utilisent les mêmes caractères mais les dessinent différement. Unicode a jugé qu'ils écrivaient une table des caractères et pas une table des glyphes (dessins), donc que les différences d'affichage devaient se faire au niveau des polices. Du coup c'est vrai que ça réduit un peu le coté pratique (surtout pour les citations) car les documents ne peuvent être relus correctement que s'ils incluent une information sur la langue.

Maintenant c'est encore pire si on utilise ISO-8859-1 ou un codage qui ne supporte qu'un alphabet. On a tout intérêt à utiliser UTF-8, rien à perdre en tout cas.

N'aie crainte, je suis tout à fait convaincu de l'intérêtde passer à UTF-8. J'y comprends pas grand chose encore, et je viens à epine d'apprendre qu'UTF-8 faisait partie d'Unicode (c'est un domaine que je n'avais jamais exploré). Ce qui me dérange beaucoup, c'est que depuis toujours, nous parlons tous d'ISO-8859-1 comme étant le charset à utiliser... J'ai l'impression qu'on a manqué de vision en ne regardant pas directement UTF-8.

Je sais bien que sur mon propre site, j'ai constamment des erreurs à prendre en charge au nom des caractères non-reconnus et c'est probablement à cause de ça. Il est donc temps de commencer à faire quelque tests pour passer vers UTF-8. Tu n'es pas le seul Ganf à éprouver des problèmes bizarres avec mon RSS, un ami me faisait part du même problème la semaine dernière, sans pour autant pouvoir en identifier la cause.

J'arrive vraiment mal à comprendre comment on a pu, chez OpenWeb et sur nos weblogs, complètement escamotter la question jusqu'à présent de l'internationnalisation.
Je suis pas très fier de moi. Je me refuse à nous juger collectivement de na pas encore avoir allumé là-dessus. :down:

> J'ai l'impression qu'on a manqué de vision en ne regardant pas directement UTF-8.

Oui et non.
Ton contenu est exclusivement français et anglais. Il n'y a aucune honte à utiliser un codage adapté à ces deux langues. Il est peu probable que dès demain tu te mettes à écrire chinois (et que ces écritures chinoises ne soient pas dans un espace distinct qui permette de mettre un charset différent du reste du site).

Dommage de ne pas y avoir assez mis d'intérêt, mais on n'a par exemple rien à reprocher à ton blog et tes articles à cause de leur ISO-8859-1.

> Ce qui me dérange beaucoup, c'est que depuis toujours, nous parlons tous
> d'ISO-8859-1 comme étant le charset à utiliser

Ça dépend pour quoi faire. Si tu fais des productions françaises il n'y a pas de mal. Si on s'attarde sur des outils qui ont pour but de vivre un peu plus indépendament que les écrits, eux devraient être en UTF-8.
Disons que l'ISO a encore ses raisons d'être. En particulier à cause du fait que ce soit le codage par défaut sur de nombreux protocoles, ou que de nombreux outils ne savent pas gérer les codages sur plusieurs octets (comme UTF-8).
Rien que pour donner un exemple : l'utilisation d'UTF-8 dans PHP n'a rien d'extrèment simple.

> Tu n'es pas le seul Ganf à éprouver des problèmes bizarres avec mon RSS, un ami
> me faisait part du même problème la semaine dernière, sans pour autant pouvoir en
> identifier la cause.

Quand j'ai constaté la chose j'ai pourtant moi aussi vu la déclaration XML de charset. Je jetterai un oeil pour chercher le problème si tu veux.

J'avais justement chercher dans la recommandation XML, mais ne trouvant pas explicitement, j'ai renoncer...


Là dessus, je ne suis plus d'accord, en tout cas, pas dans le fond. Oui, pour nous, ISO-8859-X a encore une utilité, il est clair que c'est le choix le plus juste pour écrire en langue latine. Maintenant, je pense qu'il faut pousser les considérations un peu plus loin que le simple point de vue technique.

Choisir un charset est un choix, et comme tout décision, elle est complexe à prendre et nécessite de peuser le pour et le contre. Je ne pense pas que les webmasters actuels ait toutes les clefs pour se poser ces questions.

C'est comme beaucoup de choses, le choix peut sembler donner de la liberté, mais bien souvent il restreint en créant des « gethos ». C'est un des grands problèmes du monde du libre, donner la liberté d'un choix ne veut pas forcément dire aider la personne qui va faire ce choix. Je ne suis pas en train de dire que la liberté est une chose attroce, je dis juste que la liberté est bien souvent difficile à assumer, beaucoup trop pour le commun des mortels, surtout dans des domaines dans lesquels ils ne veulent pas forcément s'investir. Il suffit de comparer le monde Mac et Linux, l'un est rigide, l'autre libre, et l'utilisateur n'est perdu que dans le second.

Ce que je veux dire est qu'il est toujours possible de choisir le charset le plus adapté au fichier (ou site web) que l'on écris. Maintenant la liberté de faire ce choix est-elle vraiment primordiale face à une intéropérabilité parfaite entre tous les fichiers ?

Encore un choix difficile...