[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux] Programmation multilangues
Kaixo!
On Tue, Aug 28, 2001 at 12:34:39PM +0200, Laurent Frisee wrote:
> pas testé mais si kylix fait comme Delphi, l\'internationalisation
> est supportée (une langue à la fois)
S'il s'agit d'i18n, c'est très bien supporté par les versions recentes
de GNU/Linux.
La façon de faire la plus courante (et la plus simple pour les traducteurs
aussi) consiste à utiliser la famille de fonctions gettext(), qui viennent
en standard avec la libc.
C'est des fonctions très simples dans leur principe, une chaîne de texte
en entrée, et en retour une chaîne de texte avec la traduction.
la chaîne avec la traduction est automatiquemment convertie au bon
encodage (donc une même traduction sers en latin1 ou en unicode, c'est
à l'utilisateur de choisir l'encodage qu'il veut).
Côté traducteur, il travaille avec des fichiers textes, c'est très simple, et
il existe plusieurs outils, ou des modes pour emacs ou vim.
Là où ça se corse un peu, c'est pour l'affichage, ça depends pas mal du
toolkit utilisé.
Le mieux, mais qui sont encore en beta, c'est des trucs comme pango/gtk2,
ou le libQT 3: support pour les fontes OpenType et Xft (donc antialiasing
et compagnie), écritures de droite à gauche, substitution de glyphes
(necessaire pour les alphabets complexes comme le devanagari etc).
ces api utilisent utf-8 en interne, il faut donc convertir si l'appli est
lancée dans une locale utilisant un autre encodage; mais les toolkits
de haut niveau fournissent tout ce qu'il faut pour ce faire; peut-être même
c'est fait de façon transparente si on utilise les fonctions d'affichage
standard du toolkit.
Pour le toolkit Gtk actuel (Gtk 1.2) il est basé sur les fonctions
d'affichage de X11, et en a donc ses limitations: écriture de gauche à
droite, et 1 caractère = 1 glyphe (pas de support des langues indiennes).
Si on utilise utf-8, il faut aussi faire attention que ce soit la bonne
fonte *-iso10646-1 qui est utilisée, car le protocole de fontes X11 suppose
qu'une fonte est toujours complète, ce qui est toujours faux pour les
fontes *-iso10646-1. (Xft permets de detecter les trous et aller chercher
en cascade dans d'autres fontes).
La libQt actuelle je connais moins, elle utilise Xft, et KDE utilise utf-8
en interne, par contre la fonctionalité de cascading pour la resolution des
glyphes n'est pas utilisée; et comme KDE/Qt reinventent beaucoup la roue
on a parfois des problèmes (notamment avec le chinois/japonais les
problèmes d'affichage sont recurrents)
Si on veut programmer soi même sans utiliser des toolkits haut niveau,
il faut aller voir la doc des fonctions mb/wc, setlocale(), nl_langinfo(),
iconv(), et d'autres.
Il faut savoir qu'un octet n'est pas necessairemment égal à un caractère,
et qu'un caractère peut avoir une largeur nulle (s'afficher en dessous ou au
dessus ou se combiner avec le caractère precedent), puis, pour l'affichage,
il faut s'amuser avec les fonctions X{mb,wc,utf8}DrawString()
Très franchemment, je ne le conseillerait pas.
donc, pour resumer, il y a déjà un très bon support pour la plupart des
langues et pour peu qu'on utilise un toolkit moderne, c'est relativemment
facile.
On s'oriente aussi vers l'unicode en interne, mais comme pendant un temps
du moins il y aura cohabitacion, il faudra prevoir des conversions de
caractères aux frontières: lire/écrire sur les fichiers (et dans le repertoire,
eg: les noms de fichiers), messages en console, etc.
La libc fournit tout ce qu'il faut pour les conversions; certaines libs
peuvent rendre cela encore plus simple (comme la libglib qui a des fonctions
pour des conversions utf8->locale et locale->utf8).
Les difficultés residront dans des aspects généraux à l'i18n, éviter les
fautes les plus courantes. Par exemple, une phrase ne doit jamais être
traduite par morceaux mais d'un bloc, car l'ordre des mots peut changer
d'une langue à l'autre, ne pas faire de suppositions sur la longueur d'un
texte, ne pas coder en dur les fontes ni la taille (certaines écritures
necessitent des tailles plus grandes pour une bonne visibilité).
ne jamais presupposer qu'un caractère non ascii pourra être affiché partout
(autremment dit, pas de non ascii dans les sources; ou alors, de l'utf-8
et forcer l'utilisation d'utf-8 en interne)
Il y a énormemment de litterature sur le sujet sur internet;
--
Ki ça vos våye bén,
Pablo Saratxaga
http://www.srtxg.easynet.be/ PGP Key available, key ID: 0x8F0E4975
[ Soyez précis dans vos sujets svp afin de déterminer directement ]
[ le type de demande... ]
[ Pour vous (dés)inscrire, aller sur http://unixtech.be/ml.php ]
[ Archives de la mailing list: http://archives.unixtech.be/linux/ ]
[ http://unixtech.be Contact: listmaster@unixtech.be ]