> > On pourrait alors dire que l'ISO8859-15 casse les logiciels qui ne
> > gèrent que l'ASCII 7 bits américain :)
> 
> Non, car si on n'utilise que des caractères ascii en travaillant en
> iso-8859-15 ça passe.

L'ascii est un sous ensemble (codé sur 7 bits) de l'iso-8859-15 donc un 
logiciel qui gère des caractères 8 bits va "gérer" le 8859 sans s'en rendre 
compte. En revanche, un logiciel qui gère du 7 bits (un logiciel de mail mal 
configuré par exemple) ne gèrera pas correctement les textes en 8859-15.
 
> Si on n'uytilise que des caractères iso-8859-15 en UTF-8 ça foire...

Ca c'est bizarre.
L'UTF-8 est calqué quasiment identiquement sur l'iso-8859-15 pour les 8 
premiers bits.
(cf  http://orwell.ru/test/ISO/_?15 )

Je penche plutôt pour une locale mal réglée dans ce cas.

> > La faiblesse est plutôt du côté des logiciels qui ne gèrent pas
> > correctement l'unicode, en effet, si on utilise la libc GNU standard
> > et qu'on utilise gettext pour la localisation, il suffit d'utiliser
> > wprintf au lieu de printf, de ne plus utiliser les "char" (en C)
> > mais les "wchar" et de veiller à ne pas tester les chaînes de
> > caractères "en dur" mais d'utiliser systématiquement des chaînes
> > localisées.
> 
> arrfff... il "suffit"...

Ce n'est pas l'utilisation d'un "il suffit" qui permet de dire que c'est 
irréaliste, c'est l'ampleur de la tâche que ça représente.

Faire un chercher/remplacer char/wchar_t, printf/wprintf, strcpy/wstrcpy, etc. 
constitue déjà l'essentiel du travail de conversion et se fait de façon tout 
à fait automatique.
Ensuite, si le texte est déjà localisé avec gettext (ou similaire), il n'y a 
plus rien à faire. Si il ne l'est pas, de toute manière ce logiciel est 
inutilisable dans toute autre langue que l'anglais et il est probablement 
déjà obsolète ou de diffusion locale uniquement et n'a pas besoin d'être 
converti si l'utilisateur ne manipule que de l'ascii ou de l'iso8859-15 puisque 
ils sont quasiment identiques bit à bit avec les caractères utf-8 codés sur 
un octet.

C'est réellement quelque chose de simple à mener.
Cf ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO-6.html#ss6.1

> EN attendant zsh ne supporte pas et debbaibn a bidouillé un slnag
> supplémentaire en utf-8...

Ca signifie avant tout que personne ne l'a fait, pas que c'est difficile ;)

Vu la faible conscience de l'intérêt de l'unicode, il est normal que tous les 
auteurs de logiciels libres n'aient pas encore franchi le pas. Je ne leur jette 
pas la pierre : si l'info ne leur est pas parvenue, ils ne vont pas le deviner 
tous seuls tant qu'ils n'ont pas besoin de manipuler d'autres langues.

> Si c'était si simple tu crois pas que pluytôt qu'avoir 2 slang dans
> debian il y en aurait un seul qui fait tout ?

Bonne remarque.
Le fait que ce soit simple au niveau d'un programme ne signifie pas que ça le 
soit au niveau d'une distribution.

On ne peut pas forcer l'usage d'unicode quand des programmes répandus (window 
managers, terminaux x, shells) ne le gèrent pas encore. Donc on doit donc 
avoir des versions distinctes dans la distribution pour :
- ceux qui ont besoin de passer en unicode parce qu'ils communiquent en 
plusieurs langages et qui sont prèts à se passer de ses logiciels pour 
d'autres moins connus ou réputés mais qui gèrent l'unicode
et pour
- ceux qui n'ont pas un besoin impératif de l'unicode et sont attachés à 
leurs logiciels "classiques".

En attendant que les logiciels les plus répandus fonctionnent parfaitement en 
unicode, on doit effectivement avoir deux systèmes en parallèle.

Laurent

Répondre à