Discussion :

[Giantrick]

Bonjour à tous,

Je voudrais avoir votre avis.

Je suis en train d'internationaliser mon site et j'hésite entre plusieurs solutions.

Laquelle est la mieux, (simple et rapide lors de l'utilisation, accès serveur et ainsi de suite)

Option 1 : MYSQL
J'ai la possibilité de créer une table qui stockera toutes les traductions et en fonction d'un script PHP je vais lire cette table pour changer les variables en fonction de la langue de l'utilisateur.

Option 2 : Fichier Texte
Utiliser des fichiers textes pour stocker la traduction comme la méthode utiliser par OScommerce

Option 3 : GetText
Je n'ai pas encore compris totalement la méthode, si elle est similaire à l'option 2 où si c'est une mise à jour lié à PHP5.2 et qui fait référence à une nouvelle méthode d'internationalisation.

Merci pour votre avis et de m'expliquer les raisons de vos choix.

Bon week-end à tous et merci d'avance.

[Palca]

Utiliser une base de données ne présente pas un grand intérêt vu que les traductions sont "statiques", donc ça consomme inutilement des ressources (à moins d'avoir un système de cache derrière).

Gettext j'ai jamais testé mais ça me semble plutôt intéressant, à voir à l'usage après mais au moins c'est fait pour ça.

Sinon il y a aussi la possibilité des fichier XML comme en ASP.NET, c'est assez facile à manipuler d'autant plus qu'avec SimpleXML on peut les traiter comme des objets.

Mais clairement c'est plus vers Gettext que je m'orienterais, je pense que c'est ce qui est de plus-en-plus utilisé.

[lunarnet76]

Salut,

effectivement Gettext est la meilleure solution car compilée donc plus rapide!
Aprés si tu veux t embeter moins et que n importe qui puisse l utiliser le mieux c est les fichiers CSV car tout le monde a Excel ou Open Office et tout le monde ne veux pas utiliser un editeur gettext et avoir a comprendre comment ca s utilise!

Par contre la pire solution c est celle del OSCommerce avec des define,c est un bordel fini

[Giantrick]

Salut,

effectivement Gettext est la meilleure solution car compilée donc plus rapide!
Aprés si tu veux t embeter moins et que n importe qui puisse l utiliser le mieux c est les fichiers CSV car tout le monde a Excel ou Open Office et tout le monde ne veux pas utiliser un editeur gettext et avoir a comprendre comment ca s utilise!

Par contre la pire solution c est celle del OSCommerce avec des define,c est un bordel fini

Merci à vous deux, pour vos commentaires, oui en effet, l'oscommerce c'est un gros bordel, il y en a partout.... mais ne connaissant pas d'autres solutions, et l'ayant mis en place pour un client, je me demandais si c'était une solution possible.... a priori c'est pas la meilleure.

Je vais me pencher sur le GetText, bien que je n'en ai pas beaucoup le temps.

Pour les fichiers CSV, je voudrai m'affranchir d'outils externes comme excel ou open office pour des raisons de liberté d'évolution.

C'est aussi pour cela que j'avais initialement opté pour la solution de la table de traduction avec des clés croisés entres tables.

Mais je me questionne toujours à la "consommation de la bande passante" pour les solutions 'mysql" et "gettext"....

Laquelle est la moins gourmande ???

Merci encore à vous deux pour vos commentaires.

J'attends d'autres points de vu avant de fermer cette discussion.

[Invité]

Bonjour,
personnellement, j'opte pour la solution BDD, Pour plusieurs raisons :
1- choix de la table de la BDD a utiliser :
(avec des tables FR-matable, EN-matable, ...)
$LANG = ... (FR, ou EN, ou ... récupéré d'un clic sur un drapeau par exemple)
$SQL = "SELECT * FROM ".$LANG."-matable ......"
2- administration :
il est possible de créer un espace "admin" ou le quidam lambda (le client, en l'occurence, ou ma mère !) pourra très facilement modifier les textes, sans la moindre connaissance en programmation.
3- modification facile, meme pour le programmeur (phpMyAdmin !)


Pour la question de "consommation de la bande passante" pour les solutions 'mysql" et "gettext"....
(sans connaitre "gettext") Si "gettext" était plus efficace qu'une BDD, alors pourquoi tous les sites fonctionnent-ils avec des BDD ?
(ceci n'engage que moi ...)

[Giantrick]

Bonjour,
personnellement, j'opte pour la solution BDD, Pour plusieurs raisons :
1- choix de la table de la BDD a utiliser :
(avec des tables FR-matable, EN-matable, ...)
$LANG = ... (FR, ou EN, ou ... récupéré d'un clic sur un drapeau par exemple)
$SQL = "SELECT * FROM ".$LANG."-matable ......"
2- administration :
il est possible de créer un espace "admin" ou le quidam lambda (le client, en l'occurence, ou ma mère !) pourra très facilement modifier les textes, sans la moindre connaissance en programmation.
3- modification facile, meme pour le programmeur (phpMyAdmin !)

Ha intéressant, cela rejoint ce que j'avais imaginé en premier jet pour mon site....

J'ai une table qui gère toutes les traductions avec des clefs identifiants

une table "Langue"

id_langue
nom_langue
actif (pour n'afficher que celle active en fonction des volontés du client)

une autre table "langue_traduction"

id_langue_traduction
id_langue (référence à la table ci-dessus du texte d'origine)
texte (texte dans la langue de l'id_langue du texte d'origine)
id_langue_traduit (référence à la langue du texte traduit)
texte_traduit (texte dans la langue traduite)

Ensuite je fais appel à un script qui va chercher les variables dans la langue sélectionné par le "drapeau" ou le menu "langue" affiché sur le site.

Est-ce que la logique est bonne ?

ps: pour les traductions j'ai créé un module d'admin avec des piles de mots et de phrases à traduire pour éviter d'aller dans phpmyadmin.

Merci encore des commentaires

[Invité]

Oui,
a priori la logique est bonne.

Ensuite, c'est juste une question de méthodologie (chacun s'organise a sa maniere)
Enfin, il faut mettre suffisamment de commentaires dans son code pour etre capable de le reprendre (et le comprendre !), meme après 6 mois !

[Giantrick]

Oui,
a priori la logique est bonne.

Ensuite, c'est juste une question de méthodologie (chacun s'organise a sa maniere)
Enfin, il faut mettre suffisamment de commentaires dans son code pour etre capable de le reprendre (et le comprendre !), meme après 6 mois !

ok j'avais écris mon script il y a près de 6 ans, et je le comprend encore... (avec quelques commentaires de compréhension bien entendu), je l'ai juste mis à jour en PHP5 et mis quelques nouveautées dedans mais ca marche plutôt bien.

Bon je me pencherais donc sur getText plus tard... pour d'autres applications peut être.

Je vous remercie tous les trois pour votre aide....

J'opte donc pour la solution "option 1 BDD".

Bonne soirée

[Palca]

Pourquoi tu as deux id de langue et textes correspondants dans ta table "langue_traduction" ?

[Giantrick]

Pourquoi tu as deux id de langue et textes correspondants dans ta table "langue_traduction" ?

id_langue_traduction // c'est l'id autoincrémenté
id_langue (référence à la table ci-dessus du texte d'origine)
texte (texte dans la langue de l'id_langue du texte d'origine)
id_langue_traduit (référence à la langue du texte traduit)
texte_traduit (texte dans la langue traduite)

En rouge c'est le texte d'origine avec l'id de la langue d'origine, et le texte dans cette langue et en Vert le texte traduit avec l'id dans la langue traduite.

Ainsi, on peut avoir de façon totalement désorganisé dans la table des textes dans toutes les langues et dans tous les sens.

L'intérêt est d'avoir un pivot entre la langue d'origine et la langue traduite afin d'afficher rapidement et directement le texte souhaité dans la langue choisi sur une simple requête.

[Palca]

Enfin ça te limite à deux langues différentes du coup.
Pourquoi ne pas avoir un seul couple clé/valeur pour chaque langue ? C'est bien plus simple je trouve.

La plupart des systèmes que j'ai vu utilisant une BDD pour des traductions fonctionnaient ainsi :
- 1 table contenant le nom de la langue ("français" par exemple) et le code correspondant ("fr").
- 1 table contenant l'id de la langue ("fr"), une clé unique ("hello" par exemple) et la valeur correspondante dans la langue désirée ("salut"), avec éventuellement le domaine de définition de la clé (global ou limité à une page ou groupe de pages).

Après il suffit pour chaque page de charger les clés de langues globales et spécifiques à la page, dans la langue par défaut, et si la langue de l'utilisateur est différente de la langue par défaut, on réécrit ces clés. De cette façon, on peut ajouter une langue, même incomplète, très facilement et sans générer d'erreurs, au pire si une clé manque, le visiteur verra le texte dans la langue par défaut (en admettant bien sûr que celle-ci soit complète).

[Giantrick]

Enfin ça te limite à deux langues différentes du coup.
Pourquoi ne pas avoir un seul couple clé/valeur pour chaque langue ? C'est bien plus simple je trouve.

La plupart des systèmes que j'ai vu utilisant une BDD pour des traductions fonctionnaient ainsi :
- 1 table contenant le nom de la langue ("français" par exemple) et le code correspondant ("fr").
- 1 table contenant l'id de la langue ("fr"), une clé unique ("hello" par exemple) et la valeur correspondante dans la langue désirée ("salut"), avec éventuellement le domaine de définition de la clé (global ou limité à une page ou groupe de pages).

Après il suffit pour chaque page de charger les clés de langues globales et spécifiques à la page, dans la langue par défaut, et si la langue de l'utilisateur est différente de la langue par défaut, on réécrit ces clés. De cette façon, on peut ajouter une langue, même incomplète, très facilement et sans générer d'erreurs, au pire si une clé manque, le visiteur verra le texte dans la langue par défaut (en admettant bien sûr que celle-ci soit complète).

Je n'ai peut être pas été clair dans mon explication, mais si tu regardes plus haut, j'ai aussi une table "langue" qui stock les id des langues (pour ne pas limiter celles-ci)

Du coup, avec mes deux tables je rejoins ce dont tu parles. J'ai juste ajouté (en rouge) l'id de la langue d'origine pour mon module de traduction ce qui facilite l'affichage à une seule requête.

et du coup, j'arrive aux mêmes résultats que ton explication.

Merci et bonne journée.

[Palca]

Du coup, avec mes deux tables je rejoins ce dont tu parles. J'ai juste ajouté (en rouge) l'id de la langue d'origine pour mon module de traduction ce qui facilite l'affichage à une seule requête.

C'est ce que je précisais justement dans mon message : ton système me semble vraiment bien dès lors que tu n'utilises que 2 langues, mais comment vas-tu faire pour en ajouter une 3ème ? Insérer à nouveau les valeurs de la langue d'origine ? Faire deux requêtes ?

Désolé je ne sais pas si je suis très clair, mais imaginons que ton site soit en 3 langues : français, anglais et espagnol. Tu aurais donc, dans un premier enregistrement :

id_langue = en
texte = hello
id_langue_traduit = fr
texte_traduit = salut

et dans un second :

id_langue = en
texte = hello
id_langue_traduit = es
texte_traduit = ola

Tu as donc à reproduire à chaque fois les valeurs de la langue par défaut.
Et si la langue du visiteur est l'anglais (qui serait ici ta langue par défaut), dans quel table vas-tu chercher ses valeurs ?

Ou alors j'ai vraiment pas compris ton système

[Giantrick]

Pour répondre plus clairement sur mon système.

J'ai plusieurs tables (en fonction des besoins) pour l'utilisation de mon site.

Chacune contient les champs suivants :

id_langue
texte

L'id_langue est l'id de la langue dans lequel le texte (du champ suivant) est écrit.

Lors de l'affichage, l'utilisateur possède une langue par défaut.

Mon script vérifie dans la table (ci-dessus) si l'id_langue est le même que la langue choisi par l'utilisateur si c'est le même il l'affiche.

Sinon il va dans la table "traduction" et il va chercher le texte d'origine dans avec l'id_langue de la table ci-dessus et trouver la traduction dans la langue choisi par l'utilisateur.

Le texte est obligatoirement traduit dans la langue choisi pour toutes les variables statiques du site.

Si il s'agit d'un texte saisie et non encore traduit pour "x" raison, c'est le texte dans la langue d'origine (de la table ci-dessus) qui est affiché avec une mention ou un code couleur indiquant que ce texte ayant été inclus récemment n'a pas encore été traduit.

Ai-je répondu à tes questions.

PS : de ce fait, il y a possibilité autant de langues que possible et d'avoir une langue par défaut avec une gestion très souple et complète des traductions.