[PHP5] CLASSE POUR GESTION MULTILANGUES
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
-
11 févr. 2008 à 19:51
Epoc22 Messages postés 198 Date d'inscription lundi 28 février 2005 Statut Membre Dernière intervention 14 novembre 2008 - 14 févr. 2008 à 11:25
Epoc22 Messages postés 198 Date d'inscription lundi 28 février 2005 Statut Membre Dernière intervention 14 novembre 2008 - 14 févr. 2008 à 11:25
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/45711-php5-classe-pour-gestion-multilangues
https://codes-sources.commentcamarche.net/source/45711-php5-classe-pour-gestion-multilangues
14 févr. 2008 à 11:25
14 févr. 2008 à 11:23
14 févr. 2008 à 10:45
14 févr. 2008 à 00:23
Et ces EN ou FR, tu les fais répêter dans les fichiers. Alors que tu les as déjà dans les noms de fichier. Ca ne sert à rien.
13 févr. 2008 à 21:48
12 févr. 2008 à 20:57
Epoc, tu dis :
"neigedhiver > Tu m'a convaincu mais pas entièrement. Le parsage d'un fichier XML demande quand même plus de ressources qu'un parsage d'un fichier INI, logique (pour moi). "
Quant à moi, j'ai dit dans mon message :
"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."
Et puis quant au parsing INI ou XML, je disais aussi :
"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."
Certes, la fonction parse_ini_file, étant native à PHP, est optimisée. Mais il faut voir le résultat : on se retrouve simplement avec un tableau.
J'ai déjà listé les avantages de XML :
- portabilité
- validation d'après un schéma XSD
Ajouté à ceux de Malalam :
- universalité des langues
- transformation XSL pour la présentation
Si tu ajoutes une fonction de cache (je répète : le fichier est parsé une fois, dans l'admin, c'est à dire là où les performances n'ont aucune importance) qui contient la déclaration d'un tableau, ce qui revient à exécuter parse_ini_file (pour arriver au même résultat quoi : un tableau tout con).
Parce que bon, faut être réaliste un peu : c'est pas top optimisé de faire un parsing à chaque affichage d'une page : la traduction n'est pas modifiée toutes les 2 secondes...
12 févr. 2008 à 20:38
=> 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.
12 févr. 2008 à 20:30
La méthode MySQL c'était un test, j'ai oublié de la virer mais bon, merci de me le dire ;-)
if (!is_null($section)) { >> okay
Pour le LANG_NAME : c'est juste pour avoir le nom de la langue en version affichable.
Pour la méthode du drapeau : c'est juste pour le fun mais bon... tant qu'à faire je la laisse.
Je vais faire la MAJ de la source dans pas longtemps. Faut que j'aille gerber.
@+
12 févr. 2008 à 20:11
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.
12 févr. 2008 à 19:43
4C1D > T'a raison, c'est plus logique, mais si le fichier INI n'existe pas ?
neigedhiver > Tu m'a convaincu mais pas entièrement. Le parsage d'un fichier XML demande quand même plus de ressources qu'un parsage d'un fichier INI, logique (pour moi).
En ce qui conçerne ton idée gérer plusieurs types de fichiers de traductions, c'est pas con mais quel serait l'intérêt exact ?
12 févr. 2008 à 02:00
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.
12 févr. 2008 à 00:25
11 févr. 2008 à 20:49
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 ;-)
11 févr. 2008 à 20:45
Pour ton code, ma foi, pas grand chose à dire : j'en ai fait un similaire, et le tien ressemble bcp à ce que j'avais fait, donc c'est que c'est bon ;-)
Sauf que j'étais passé par du xml moi, parce que tu devrais penser à un truc : les langues dont l'alphabet est très différent du nôtre...tu vas être très emmerdé pour gérer ces fichiers, même si ton code n'est pas là pour les gérer, mais pour les exploiter, j'en conviens.
J'avais pensé au templating pour remplacer des valeurs, mais finalement j'avais décidé que je n'en avais pas besoin (parce que tu peux toujours foutre une "constante" et la remplacer dans ton message après coup).Mais ça reste une bonne idée.
11 févr. 2008 à 20:17
Suggestion de traduction ? Mon anglais est pas bon...
11 févr. 2008 à 19:51
juste pour te vanner (pas méchamment hein) un petit peu :
# * // FR : Il y a actuellement 12 commentaires au total dans la base de données.
# * // EN : It was actually 12 comments in total in the database.
J'espère que ce n'est pas toi qui fait tes traductions en anglais en général ;-)