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: [EMAIL PROTECTED] ]
