Internationalisation : i18n Vous connaissez ?
#21
Posté 06 juin 2004 - 13:37
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?
#23
Posté 06 juin 2004 - 22:53
Denis, le samedi 05 juin 2004, 18:29, a dit :
Alors, je suis dans les choux ?
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
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
Louisa Paulin, une femme qui nous vient de l'avenir...
Poésie occitane
#24
Posté 07 juin 2004 - 10:42
Denis, le dimanche 06 juin 2004, 14:33, a dit :
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 ?
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.
#25
Posté 07 juin 2004 - 11:22
Merci pour cette explication détaillée anubis
Anubis, le lundi 07 juin 2004, 11:42, a dit :
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 ?
Monique
en campagne pour des sites de qualité, conformes aux standards et accessibles... avec mon navigateur préféré (Firefox) et les Bonnes pratiques qualité pour les sites Web (Opquast)
Webatou : accessibilité et qualité des sites Web
#26
Posté 07 juin 2004 - 12:17
Monique, le lundi 07 juin 2004, 11:22, a dit :
- 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
Monique, le lundi 07 juin 2004, 11:22, a dit :
Erreur dans le code ?
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é.
Ce message a été modifié par Anubis : 07 juin 2004 - 12:23
#27
Posté 07 juin 2004 - 16:28
Citation
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)
Citation
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é).
Citation
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)
Citation
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.
Éric Daspet
#28
Posté 07 juin 2004 - 17:04
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.
#29
Posté 07 juin 2004 - 18:19
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.
Éric Daspet
#30
Posté 07 juin 2004 - 18:44
Citation
(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)
J'avais justement chercher dans la recommandation XML, mais ne trouvant pas explicitement, j'ai renoncer...
Citation
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.
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...
1 utilisateur(s) dans ce sujet
0 membre(s), 1 invité(s), 0 utilisateur(s) anonyme(s)
- MSN/Bing

Connexion
Inscription
Aide

Haut
Citer






