[PHP5] CLASSE POUR GESTION MULTILANGUES

Commentaire de Epoc22 le 11/02/2008 20:17:46

Euuuuuh merci de ta remarque, j'en tient compte !
Suggestion de traduction ? Mon anglais est pas bon...

Commentaire de Epoc22 le 11/02/2008 20:49:53

Merci pour la traduc, je met à jour tout de suite.
Je préfère les fichiers du genre INI parce qu'avec un fichier XML il serait trop gros (de taille) avec les balises te tout...
Pour les caractères spéciaux : oui, ça va être chiant, mais il y a toujours des déviations possibles.
Merci de ton commentaire ;-)

Commentaire de neigedhiver le 12/02/2008 02:00:55

Salut,

J'avoue, j'ai pas regardé le code. Voyant que Malalam dit que c'est bon, je lui fais confiance.

Juste une remarque :
"Je préfère les fichiers du genre INI parce qu'avec un fichier XML il serait trop gros (de taille) avec les balises te tout..."

Je suis pas complètement d'accord avec toi.
La taille d'un fichier, ça n'a plus grande importance de nos jours...Surtout que là, c'est même pas un fichier envoyé au client, mais uniquement exploité par l'appli côté serveur (ça peut jouer pour un javascript par exemple).
La question à se poser, ce n'est pas que le fichier soit volumineux, mais qu'il soit exploitable avec de bonnes performances.
En d'autres termes, je ne sais pas si exploiter un fichier .INI est plus rapide qu'un fichier XML(en toute objectivité : c'est à dire que je n'en ai réellement aucune idée, sans aucun a priori). Il peut y avoir une question de souplesse également.
Et puis avec un fichier XML, tu peux t'assurer qu'il est conforme à un schéma (.XSD) et le valider avant de l'exploiter, ce qui permet de s'assurer qu'il sera correctement traité.
Les fonctions pour exploiter/gérer des fichiers XML étant des fonctions écrites en C et présentes sous forme d'extensions PHP, elles sont optimisées pour ce travail.
Et puis un fichier XML contenant des données peut aussi être "mis en cache" sous forme d'un fichier PHP dans lequel est simplement défini un tableau contenant les traductions, ce qui évite de le parser à chaque fois.

Pour terminer, ce qui serait leplus top du meilleur bien, ce serait d'avoir la possibilité de gérer plusieurs types de fichiers de traductions... .ini, .txt, .php, .xml, .po, etc. Avec une classe d'abstraction pour la gestion par l'utilisateur (IHM) et une classe concrète pour chaque type de fichier.
Mais bon, c'est peut-être pas ton idée de départ, c'est peut-être sans objet dans ton projet, ou que sais-je...
Je dis ça juste comme ça :)

Bonne continuation.

Commentaire de malalam le 12/02/2008 20:11:18 administrateur CS

L'intérêt de plusieurs fichiers de traduction serait le même que pour une classe d'abstraction de db, de gérer plusieurs types de db. Mais bon...
Utiliser le XML pour internationaliser un site a d'autres avantages : déjà, un fichier xml est bien plus lisible qu'un fichier ini. C'est aussi nettement plus portable...c'est un format standard. Tu veux montrer tes traductions à un client ? Un petit xsl, et le tour est joué. Avec tes fichiers ini, tu devras créer un script dédié pour exporter ça sous un format user-friendly.
Encore une fois, j'insiste sur les difficultés de gérer des langues aux alphabets très différents avec ton système : ma classe (et mon back-office) gère aussi bien l'anglais que le chinois ou le bulgare. Le xml supporte l'encodage.
Quant à parser un fichier ini ou un fichier xml, je ne suis pas certain que la différence de ressources soit énorme, si tant ait qu'il y en ait une : dans les deux cas, on a un parsing.
Et puis quitte à utiliser des fichiers plats avec une syntaxe néanmoins particulière, pourquoi à ce compte ne pas passer par gettext ?

Concernant le code, j'ai quelques griefs ceci dit, après l'avoir bien regardé :
Le constructeur, comme le dit 4C1D ne doit pas contenir d'exit. Tu dois, puisque tu codes en POO php5, passer par les exceptions.
La méthode permettant d'aller chercher l'image du drapeau est franchement de trop...
De même que celle dédiée à mysql : déjà, si j'utilise une autre db, je suis embêté et je me la trimballe pour rien, mais de plus, si je n'utilise pas du tout de db. Qui plus est, je dois ouvrir ma connexion en dehors, et la classe utilisera cette connexion globale...c'est maladroit et peut s'avérer dangereux selon les cas.
if (!empty($section)) {
devrait devenir
if (!is_null($section)) {
je pinaille, mais c'est plus correct. Et puis si je veux appeler ma section 0...;-)
L'obligation de passer LANG_NAME dans le fichier ini alors qu'on l'a déjà sur le nom du fichier...bon...tu aurais pu t'en passer.

Un objet gérant des traductions est appelé souvent...il faut donc qu'il soit le plus léger possible, fasse uniquement le boulot essentiel. C'est pour ça que j'estime que tes méthodes pour le drapeau et mysql sont vraiment de trop.

Commentaire de malalam le 12/02/2008 20:38:59 administrateur CS

Pour le LANG_NAME : c'est juste pour avoir le nom de la langue en version affichable.
=> tu peux très bien le stocker dans ton tableau, là n'est pas le problème : c'est juste que tu peux le faire au niveau du dossier, pas la peine de le récupérer dans le fichier ini.

Commentaire de Epoc22 le 13/02/2008 21:48:54

Mmm c'est vrai neigedhiver. Par contre, malalam : "c'est juste que tu peux le faire au niveau du dossier" > comment ça ?

Commentaire de Epoc22 le 14/02/2008 10:45:52

? Mes dossiers ?