[PHP5.1] O-LOC : CLASSE ET BACKOFFICE D'INTERNATIONALISATION
codefalse
Messages postés
1123
Date d'inscription
mardi 8 janvier 2002
Statut
Modérateur
Dernière intervention
21 avril 2009
-
2 nov. 2007 à 23:22
stu76 Messages postés 186 Date d'inscription samedi 5 mars 2005 Statut Membre Dernière intervention 17 février 2008 - 28 janv. 2008 à 14:40
stu76 Messages postés 186 Date d'inscription samedi 5 mars 2005 Statut Membre Dernière intervention 17 février 2008 - 28 janv. 2008 à 14:40
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/44592-php5-1-o-loc-classe-et-backoffice-d-internationalisation
https://codes-sources.commentcamarche.net/source/44592-php5-1-o-loc-classe-et-backoffice-d-internationalisation
28 janv. 2008 à 14:40
++
4 janv. 2008 à 19:03
Ca fait plaisir de te recroiser!
C'est une très bonne idée ce que tu proposes là! Ce serait plus joli à utiliser en effet, et plus pratique. Je vais me pencher là-dessus, merci :-)
3 janv. 2008 à 15:52
Pourquoi ne pas créer une classe dynamique au moment du parsing XML ? Ou alors, remplir des données dans une classe :
<?xml>
<root>
<translate id="nom_de_la_constante">La traduction qui va avec</translate>
<translate id="nom_de_la_constante_no2">L'autre traduction </translate>
</root>
<?php
// Eventuellement y mettre un Singleton au fesses, c'est plus sympa :D
class Language {
private $tab = array();
private $init = false;
public function setInit($bool) {
$this->init = $bool;
}
public function __set($id, $traduc) {
if ( $this->init) $this->$tab[$id] = $traduc;
}
public function __get($id) {
if ( !$this->init ) return $this->tab[$id];
}
}
// Tu fais ton parsing XML, et tu introduis ton couple ID/traduc dans la classe
// Puis, l'appel ce fait comme ceci :
$lang = new Language(...);
echo $lang->ROOT;
echo $lang->WELCOME_HOME;
echo $lang->KIKOO;
// ET puis voila :) Eventuellement, la classe de langage peut se charger du parsing XML à l'init :
$lang = new Language('fr');
// Et on charge les paramètres français depuis le fichier XML francais.
Encore mieux, si on doit faire du multilangage sur un site :
$lang_fr = new Factory_Language('fr');
$lang_de = new Factory_Language('de');
// Et quand on est dans une classe, on rappèle la factory qui se charge de faire un singleton :
class x {
public function x() {
$lang_fr = new Factory_Language('fr');
// stuf...
}
}
Une solution rapide et assez efficace. Reste à savoir si ca tiens la route sur x00000 de visiteurs à la secondes :)
8 nov. 2007 à 12:47
Sur les sites internationaux où l'on a utilisé des constantes, si par malheur on oubli une constante dans une trad, on a une belle erreur undefined constant bla bla.
Là, avec ce principe, ce n'est plus le cas : plus d'erreur, et la traduction dans la langue par défaut est affichée (bon, il faut qu'elle soit définie dans la langue par défaut quand même lol, mais c'est une sécurité en plus). D'ailleurs je pense ajouter de ne rien afficher si ni la langue demandée ni la langue par défaut n'ont las traduction demandée (je ne sais plus si je l'ai fait ou non dans oLocale : le backoffice lui, gère ça très bien).
Merci en tous cas :-)
8 nov. 2007 à 12:22
J'ai longtemps hésité à utiliser les fichiers xml pour l'internationalisation de mes codes mais je travail avec des constantes et je ne peut me résoudre à les abandoner... lol... non c'est surtout que les constantes ont l'avantage de pouvoir être appelées de partout à tout niveau sans avoir à passer par la globalisation d'une variable, d'un objet ou d'avoir à passer par un singleton... mais le xml me séduit quand même comme format de stockage... plus souple... ou alors il faudrait que la class fasse les define() au moment du chargement du fichier mais je trouve ça moins propre et le problème après c'est que tu peux plus changer de langue en cours de route... .. .
@ tchaOo°
8 nov. 2007 à 08:00
Les dules ne "font" rien. C'est juste pour mieux organiser les traductions.
Je reprends le principe global de la structure de ma gestion des traductions dans le backoffice :
il permet une gestion multisites, donc le premier niveau, c'est le site web. Ensuite, chaque site à son internationalisation, puis ses langues.
Dans le répertoire des langues, il y a plusieurs fichiers xml 2 dans le zip) : ce sont les modules. Et dans les modules (donc dans les fichiers), il y a les traductions liées à ces modules.
Exemples de modules :
"error" : on y regroupera toutes les erreurs : error_file_not_found, error_page_not_found etc.
"menu" : on y regroupera les traductions de notre menu : menu_home, menu_source_codes, menu_forum... par exemple.
Le principe étant qu'un nom de module doit être un nom de fichier valide SANS underscore.
Un nom de "constante" de traduction doit être un nom d'élément xml valide, préfixé par le nom de son module suivi d'un underscore, puis ce que l'on veut. Le choix de préfixer la constante par le nom de son module, là encore; c'est juste pour de la lisibilité : quand tu mates ton code, tu sais tout de suite quels modules sont utilisés par tes traductions.
Dans le zip, il y a 2 modules donc : "err" et "mx".
Pour gettext, si je ne remets pas en question l'intérêt de l'extension, je trouve sa mise en place trop complexe. Le fait que ce ne soit pas en built-in dans php oblige éventuellement à recompiler php...déjà, sur un serveur en prod, c'est chiant. Ensuite, faire un backoffice de gestion est plus compliqué, vu la structure des fichiers de traduction. Et au final, ça n'apporte pas grand chose de plus.
8 nov. 2007 à 00:30
En fait mon idée se basait sur l'usage de gettext, sauf que cette fonction se base sur les variables systeme, ou les crées le cas échéant, mais du coup, c'est accessible pour tout le systeme, que ici, ce n'est pas le cas, du coup faire gettext ("mon message qui fait 20 lignes") ca perd tout son interet ! en effet ! :)
Sinon, tu pourrais m'expliquer vite fait que font tes modules s'il te plait ? car j'ai un peu du mal à les comprendre, et si je me trompe pas, il n'y en a pas dans le zip (donc impossible à traduire à partir du code :p)
7 nov. 2007 à 22:44
Et cela ne bloque pas au niveau de la quantité.
Si j'écris "welcome_wish_to_newcomers" et que derrière, j'ai mon texte de bienvenue aux nouveaux venus sur mon site et que ce texte fait 20 lignes...je pense que je m'y retrouverai bien mieux dans mes traductions que toi qui va écrire echo gettext('mes 20 lignes en entier'). Tes fichiers de traduction risquent d'être vite incompréhensibles.
C'est un peu comme si tu me disais qu'au lieu de définir la constante de mon sql host ainsi :
define('HOST', 'www.mydbserver-myprovider.com');
je devrais la définir ainsi:
define('www.mydbserver-myprovider.com', 'www.mydbserver-myprovider.com');
Perso, je m'y retrouve mieux avec HOST.
Surtout que si je change la valeur de HOST, j'aurai:
define('HOST', 'www.newmydbserver-newmyprovider.com');
alors que toi tu auras
define('www.mydbserver-myprovider.com', 'www.newmydbserver-newmyprovider.com');
bref, mes constantes ne bougent pas, dans mes traudctions. error_file_not_found définit bien ce que c'est. Même si j'en change la trduction de "Le fichier n'a pas été trouvé", à "Je n'ai pas pu trouver le fichier demandé, vérifiez s'il existe toujours".
Si toi t'as mis comme "constante" : "Le fichier n'a pas été trouvé", c'est carrément source de mélangeage de pédales :-) si tu dois y mettre la 2de traduction par la suite.
Mais ça reste un point de vue hein :-) Je préfère ma façon de faire, sur le coup; mais chacun a sa façon de s'organiser, c'est normal :-)
7 nov. 2007 à 22:26
7 nov. 2007 à 19:47
7 nov. 2007 à 18:38
mx_play1 est un simple exemple tiré d'un site dont je n'ai pas défini les "constantes".
Imaginons un module error(déjà, j'ai des modules) :
je vais avoir ces constantes :
error_login_failed
error_file_not_found
erro_page_not_found
etc...
Là, c'est parlant. Pas moins en tous cas que "welcome to my website", et c'est plus court à écrire.
Ensuite, je fais via ma classe oLocale :
echo getMsg('error_file_not_found');
Et basta.
TU crées tes modules et tes constantes, donc TU sais ce que tu y mets. Donc tu les connais.
Le but est qu'elles soient explicites, mais ça, c'est comme tout en programmation : les variables doivent être explicites, les noms de méthodes aussi, etc.
Bref, ma classe oLocale fonctionne exactement comme tu l'indiques (la notion de modules en plus, ce qui permet de scinder un peu tes traductions et de ne pas avoir des fichiers de 3km de long...), et de structurer, évidemment.
Et mon backoffice permet de gérer ces traductions, d'en créer, d'en modifier, etc...ce, manuellement, ou via upload de fichier.
7 nov. 2007 à 17:45
Le probleme, c'est qu'il faut savoir que mx_play1 veut dire "veuillez utiliser la souris" nan ?
Pourquoi ne pas se baser sur le principe (grossomodo) de gettext ? genre
eco getMsg ("Welcome to my website"); et dans ton xml tu aurai un truc du genre
<lang>
<FR>
<message>
<original><[CDATA[Welcome to my website]]></original>
<translated>Bienvenue sur mon site</translated>
</message>
</FR>
</lang
En gros ? comme ca tu fait une requete Xpath qui recherche dans /lang/$LANG/message/original/. et qui affiche le ../translated/. ?
(version simplifiée de l'idée biensur :p)
7 nov. 2007 à 16:37
7 nov. 2007 à 16:01
Peut-être parce que l'extension gettext n'est pas installée par défaut et que selon les cas c'est tout simplement pas possible de l'installer...
7 nov. 2007 à 15:22
5 nov. 2007 à 00:23
1) on est sur un site ou une appli et on constate qu'une phrase doit être reformulée (cas le plus fréquent )
2) on va dans le backoff de la gestion des traductions et on tape par exemple les premiers mots de la recherche,
3) une liste apparait avec toutes les propositions et on change la traduction.
Mais en fait ça fonctionne un petit peu différement de toi : il n'y a pas de notion de module, mais de "balises". Tu ajoutes des balises (avec par exemple le nom de la page ou justement du module) et tu associes une traduction.
Donc à ce niveau, comme je "perds" une couche, c'est un petit peu plus pénible. Mais je pense refaire cette appli en fait.
En revanche j'ai une autre notion : les paramètres. Peut-être que tu as cette fonctionnalité, j'ai pas tout regardé de ton appli.
exemple avec la balise "TEST"
Dans une traduction en FR tu tapes : "Bonjour, nous sommes le [madate], et il fait beau".
Pour l'affichage, 2 solutions : en php dans un controleur (parce que j'ai fait mon framework enfait ) :
$this->getOFTraduction('test', array('madate'=> date('%d / %m / %Y')));
ou alors, pas de php, mais dans un plugin smarty que j'ai développé (rien de génial) :
{ofts balise="test" madate="04 / 11 / 2007"}
ou encore dans un controleur :
$this->getSmarty()->assign('madate', date('%d / %m / %Y') );
et dans le template
{ofts balise="test" madate="$madate"}
on a fait quelques sites avec ce système, ça marche plutôt bien et l'interface est très agréable... y a juste ce problème de recherches.
4 nov. 2007 à 23:53
Mais oui évidemment, si on a énormément de traductions, ça devient forcément plus problématique. Mais je ne suis pas convaincu par la recherche par mots clefs : il faut connaître les mots existants dans une langue compréhensible! Parce que le bulgare et moi, ça fait 2. Et ne chercher que le français, ou l'anglais, ne sera pas forcément très pertinent. Surtout pour les bulgares ;-) M'enfin oui, pourquoi pas, c'est une bonne idée à creuser. Ce n'est pas très difficile en xml...ça risque juste d'être un peu long, comme traitement.
Tu as fait quoi toi, sur ton appli ? recherche, donc ? Ou tu es en passe de le faire ?
Et merci :-)
4 nov. 2007 à 23:21
Comme mon système tu as le même souci : si il y a 250 traductions dans une appli ça va vite devenir le bordel. Il faudrait donc que l'on puisse chercher une traduc rapidement avec des mots clés sans aller dans le code pour voir à quel module ça correspond.
Pout l'encodage, c'est bien d'obliger personne à utiliser tel ou tel encodage, mais honnêtement l'UTF-8 ne m'a jamais déçu ;)
A part ça excellent, source très complète :)
4 nov. 2007 à 12:37
Pour l'encodage des caractères, tu as mieux exprimé que moi le pourquoi de sa nécessité ;)
Cela dit, c'est pas parce que tu partages que ça doit être universel... C'est ton choix de faire que ce soit le plus ouvert possible, après, libre à chacun de faire ce qu'il veut et d'ajouter la gestion de l'encodage, ou de n'importe quoi qui lui plait.
4 nov. 2007 à 12:24
4 nov. 2007 à 12:22
$xml = '<translations>
</translations>';
je vais avoir un \n au milieu, forcément).
Si je peux me permettre un conseil (qui rebondit sur ta question dans le forum) : utilise simplXML pour parcourir tes flux, c'est plus pratique, mais DOM pour les modifier ou les construire. simpleXML ne permet pas d'ajouter de noeud, ou d'en supprimer. Juste d'en modifier. Et encore, pas beaucoup. Pour l'instant en tous cas, je pense que php6 fera encore un peu grossir simpleXML, comme l'on faites les différentes version de php5 au fil du temps.
3 nov. 2007 à 13:45
Pour terminer, ce que je reproche à SimpleXMLElement::asXML() c'est de ne pas indenter le contenu. Je sais, c'est stupide, mais bon, j'ai cet a priori à la noix...
Mais comme tu m'as convaincu, ben... De toute façon je comptais développer une sorte de back office. A défaut d'application complète, au moins les outils pour gérer tout ça. Bref... Tout ça nourrit ma réflexion, et c'est très bien ;)
3 nov. 2007 à 12:39
Certaines personnes construisent leur flux XML à partir d'autres données...du coup, ils vont faire ceci :
foreach($aData as $sContentsKey => $sContents) {
$sXML .= '<'.$sContentsKey.'>'.$sContents.'</'.^sContentsKey.'>'."\n";
}
de manière à ce que, en ouvrant leur fichier xml dans un éditeur lambda, les retours chariot soient visibles. Le retour chariot ne sera PAS pris en compte dans ton flux xml. Ceci dit, ça reste une hérésie pour moi. Si on veut visualiser le flux (je parle bien du flux, pas des données qu'il décrit), autant utiliser une application dédiée telle que XMLSpy.
Si on doit voir ses données, là, ça dépend du contexte. C'est ce que fait mon back-office :
tu ne vois que les données, le flux est transparent. Tu peux les modifier, en créer...ça reste transparent, tu ne travailles que sur les données, PAS sur le flux.
C'est à l'application PHP de vérifier la conformité des données qu'elle traite. Et évidemment, à l'utilisateur d'utiliser correctement les données selon son application : essaye d'ouvrir un fichier .doc avec Zend Studio...tu verras ce qu'il dit. Ou d'utiliser un dvd playstation3 sur ton pc. Et mieux, ouvre un fichier .doc sous texpad ou notepad...ah ça, tu verras quelque chose... ;-) Mais pas forcément ce que tu t'attendais à voir. Pourtant, le fichier .doc est "propre"...et l'application textpad très bien codée.
Si tu veux visualiser ton .doc dans de bonnes conditions, tu utilises Word (ou OpenOffice, comme moi).
3 nov. 2007 à 12:24
"Néanmoins, étant donnée qu'à l'origine elle est destinée à mon équipe, je l'ai construite de manière à ce qu'elle fonctionne chez moi :-)"
>> Je suis bien d'accord... Je parlais seulement de théorie, pas de mise en application ;)
"Pour simpleXML, pourquoi veux tu utilise simpleXMLElement::asXML() ? Cette méthode sert surtout pour du debug et éventuellement sauvegarder un flux xml avec un bête file_put_contents(). Elle ne sert pas à travailler sur le flux. Si tyu veux afficher le textNode d'un élément de ton flux, tu dois aller le chercher avec xpath par exemple."
>> En lecure, je n'utilise pas xPath, je parcours l'objet pour stocker le contenu XML dans un tableau, plus facile, à mon sens, pour accéder aux chaines traduites.
Par contre, il me semblait que asXML servait à la sortie du XML, éventuellement dans un fichier... Le but de cette fonction ne serait-il alors pas de sauvegarder un fichier ?
"J'ai souvent vu des gens construire des flux XML en y ajoutant des \n afin de le formatter avant de le sauvegarder."
>> Euh... Là, je ne te suis pas... Il faut l'ajouter où le \n, parce que depuis un objet simpleXML, on ne peut pas rajouter, me semble-t-il de caractères en dehors des balises...
"Quand je vais les "regarder", j'utilise alors un logiciel tel que XMLSpy, ou même IE, qui le formattent eux-même pour l'affichage."
>> C'est pas faux... De mon côté, j'envisage une application (même rôle que ton back office) qui permet de visualiser/éditer les fichiers de traduction.
Mais bon, quand on aime avoir accès à tout, c'est aussi bien quand c'est "propre" ;) Parce qu'une application en PHP (par exemple), si le code est mal formé pour une raison x ou y, elle n'affichera rien... Un éditeur de texte affichera toujours le contenu...
Merci pour tes réponses en tout cas, la discussion est intéressante... Vais continuer de potasser mes classes... Je pensais avoir terminé ma classe d'abstraction bdd, mais... en fait non... Dire que ça fait plus d'un an que je suis dessus lol
3 nov. 2007 à 12:04
3 nov. 2007 à 10:55
Et puis vu le support incroyablement puissant de php pour l'utf-8...ahem...
Je pense que ce back-office sera profondément modifié le jour où php6 et son support en interne de l'unicode sortira. Vivement...:-)
Attention, le xml est un format de description de données. S'il décrit des données html, cela ne va nullement à l'encontre du concept MVC de mettre des balises html dans des cadata. D'ailleurs, les cdata servent plus ou moins à ça. J'ai trouvé largement préférable de se laisser la possibilité de créer des "constantes" de traductions contenant de la mise en page plutôt que d'obliger à découper un texte selon sa mise en page. Cela peut vite devenir très lourd. Rien n'empêche néanmoins de le faire, l'application laisse le choix, simplement.
Attention, ne confonds pas le code que tu vois là, celui que j'ai décide de mettre dans le conteneur de visualisation du code, et la classe utilitaire permettant de gérer l'affichage et le choix des traductions sur une application web : le code que tu vois là est le code du coeur du back-office. Il n'est nullement destiné à être instancié et appelé dans un autre code. C'est une application. On la lance via le fichier back.office.php et on l'utilise.
La classe oLocale, elle, dont le code est beaucoup plus simple, est destinée à être instanciée et utilisée dans un autre code, et sert à choisir et afficher les traductions.Elle se base sur des fichiers xml qui PEUVENT être générés par le back-office puisqu'il utilise la structure attendue. Mais elle peut très bien servir sans le back-office.
Pour simpleXML, pourquoi veux tu utilise simpleXMLElement::asXML() ? Cette méthode sert surtout pour du debug et éventuellement sauvegarder un flux xml avec un bête file_put_contents(). Elle ne sert pas à travailler sur le flux. Si tyu veux afficher le textNode d'un élément de ton flux, tu dois aller le chercher avec xpath par exemple.
Et si tu parles de ce que simpleXMLElement::asXML() donne si on l'utilise pour sauvegardert un flux dans un fichier, bah...je n'ai jamais été d'accord avec ça. Lol. J'ai souvent vu des gens construire des flux XML en y ajoutant des \n afin de le formatter avant de le sauvegarder. Pour moi, ça n'est pas le but. Je peux aussi bien sauvegarder mes flux xml sur une seule ligne. Quand je vais les "regarder", j'utilise alors un logiciel tel que XMLSpy, ou même IE, qui le formattent eux-même pour l'affichage. Les \n, php s'en fout. Il n'en a pas besoin. Ni aucun autre moyen detravailler sur les flux XML d'ailleurs. C'est juste pour nous...et à ce compte, je préfère utiliser les outils de visualisation adéquats.
Mais ça reste un avis personnel :-)
Pour ta dernière question : tout applicatif impose ses normes. Si elles sont judicieuses, les gens s'y plient volontiers. A toi de voir, donc : faire quelque chose proposant un très large éventail de possibilités...mais du coup complexe et pouvant rebuter ceux qui cherchent une application pour les aider à réaliser quelque chose simplement... ou imposer une norme judicieuse et efficace qui satisfera le plus grand nombre, et décevra certains hardcore users qui aiment que les applicatifs se plient à LEURS exigeances.
Le plus souvent, cela va dépendre du contexte de ton applicatif : à quoi est-il réellement destiné. Un framework (au hasard) doit être exhaustif...et simplifier la complexité, si j'ose dire. Un framework reste compliqué à utiliser, il demande de l'investissement. MAIS, l'exhaustivité de ce qu'il propose, il en simplifie quand même l'usage. Bref, pour un framework, il vaut mieux être exhasutif, oui. Pour un CMS, il vaut mieux ne pas l'être et imposer des normes simples et efficaces.
3 nov. 2007 à 02:42
>> Certes. Cependant, question internationalisation,justement, l'utf-8 serait, à mon sens plus approprié, puisque plus universel... M'enfin ça, tu le sais, hein...
"Pour les < et >, c'est inutile, car les flux xml générés par le back-office encapsulent leurs textNode dans des cdata. Les caractères tels que < et > ne sont donc pas interprêté. C'est d'ailleurs tout l'intérêt : cela permet d'y inclure du html...pour la mise en page :-)"
>> Au premier coup d'oeil, j'ai trouvé que ça alourdissait la lecture du fichier XML. Mais l'avantage que tu cites est loin d'être négligeable...
Cependant, dans une logique MVC, si on sépare correctement le traitement de la présentation, du html dans les fichiers de traduction, c'est superflu... Mais bon... (je chipote, je chipote...)
Bref, merci de partager cette source. Parce que comme toi, je constate que l'internationalisation, c'est un p****n de galère, quand même.
Même si je n'utiliserai probablement pas ta classe telle quelle (et je te prie de m'en excuser ^^), au moins, j'ai un vrai quelque chose à me mettre sous la dent côté inspiration, logique, tout ça.
J'utilise aussi SimpleXML pour la gestion de mes fichiers de langue XML, mais je suis vraiment rebuté par la sortie de la méthode asXML. Y'a bien une source sur la doc de php pour mettre en forme joliment, mais c'est peut-être lourd en terme de perfs.
De mon côté, je suis un peu perdu dans toutes les considérations liées à la localisation : langue (nom court, nom long, nom traduit, ...), fuseau horaire, le format d'affichage de la date, encodage, direction, ... Du mal à faire le tri entre ce qui est nécessaire et superflu...
Et puis pour couronner le tout, j'aimerais avoir une classe d'exception qui traduit les messages d'erreur. Et si possible, qui les affiche correctement avec Smarty... Et si en plus j'y ajoute mon système de plugins...
Tiens une question bête : penses-tu qu'il serait judicieux, dans un contexte d'application distribuée en GPL de gérer plusieurs formats de fichiers de langue (xml, ini, ...) ?
3 nov. 2007 à 01:34
En l'occurence, là, j'ai géré ça en iso-8859-1 qui suffit parfaitement à la tâche et s'implémente facilement sur des sites européens, qui plus est. Mais je rajouterai une possibilité de choisir l'encodage des fichiers xml, c'est prévu.
Ceci dit, généralement, quand je bosse avec du xml, je bosse en utf-8, oui. Mais là je me suis rendu compte que cela fonctionnait parfaitement avec desflux en iso-8859-1.
Pour les < et >, c'est inutile, car les flux xml générés par le back-office encapsulent leurs textNode dans des cdata. Les caractères tels que < et > ne sont donc pas interprêté. C'est d'ailleurs tout l'intérêt : cela permet d'y inclure du html...pour la mise en page :-)
J'ai fait ce back-office parce que ces temps-ci, à mon taf, nous faisons face à une forte poussées des sites internationaux. J'en avais marre de gérer ça tant bien que mal, ça prend énormément de temps. J'ai donc décidé d'imposer un type de fichiers que doivent nous fournir nos traducteur (le template xls), et de monter ce back-office qui s'appuie sur la structure xml de ma classe oLocale, permettant de gérer l'affichage des traductions.
Bref pour la 1ère fois, je mets ici une vraie application que j'utilise dans mon taf, et pas simplement un package utilitaire, ce que je ne fais normalement jamais. Mais là, je me suis dit que l'internationalisation, c'était une plaie, et que ça pourrait sans douter aider quelques personnes.
2 nov. 2007 à 23:33
Intéressante, cette source... D'autant plus, pour moi, que je me creuse la tête ces derniers jours sur une classe d'internationalisation... Je vais donc regarder en détails ce que tu as fait ^^
Petite question : tu ne gères pas la direction "ltr" ou "rtl" ? Ou alors j'ai mal vu ?
Autre chose : penses-tu qu'il soit pertinent de s'intéresser à l'encodage des caractères lors de l'affichage, ou bien est-ce que le tout-utf8 est ta devise ? (comme elle aurait tendance à être la mienne)
C'est tout pour le moment ;o)
2 nov. 2007 à 23:22
Ya pas à dire, c'est du bon! tres bon meme ... comme toujours :)
Je met 11 ... ah bah nan, 10 ! :)