PHP|Débutant :: Forums

Bonjour,

Le tuto est bien et il montre le principe. Il a cependant un inconvénient, c'est qu'il n'utilise pas le cookie qu'il dit utiliser, et vérifie à chaque chargement la présence de la langue dans l'url pour rerouter sur le chargement du bon fichier langue. Or le paramètre de l'URL (accessible donc en GET) n'est disponible que lors du premier envoie de la requête HTTP au serveur, et il peut être sympa de décharger ensuite l'url de ce paramètre pour d'autre traitements.
Personnellement, je stockerais en $_SESSION plutôt qu'avec $_COOKIE car beaucoup d'utilisateurs désactivent les cookies pour éviter les tracking cookies de certains sites peu scrupuleux.

Si vous stockez donc votre langue dans $_SESSION['lang'] et que le choix des langues disponibles est inclus dans un tableau par exemple, il vous suffit de faire un truc du genre:

Bonnes fêtes

Dernière modification par Jc (29-12-2013 13:19:12)

Bonjour,

Pour la méthode présentée et proposée sur le tuto de ce site et pour répondre à votre question, elle est similaire à celle employée dans les programmes compilés avec un fichier de ressource, l'include appelant le dit fichier de ressources.

Les inconvénients et avantages à cette méthode:
- Elle est adaptée pour la traduction de menus, fonctionnalités, libellés de formulaires, bref à tout contenu bref/limité et statique proposé par le site.
- Elle est inadaptée pour du contenu riche (plusieurs lignes) où la traduction nécessite plus une traduction de contexte que littérale et/ou générique.
- Si la volumétrie de contenu est importante le nombre de définitions de constantes stockant ces traductions le sera d'autant, en ayant pour conséquences
a) une mobilisation mémoire au niveau de PHP à un instant t pouvant être non négligeable surtout si le site connaît un fort traffic.
b) Seule une partie de ces constantes chargées en mémoire peuvent être requêtées par le client et donc pertinentes pour l'application.

Pour vous donner une idée, dans une petite application compilée, le nombre de références de localisation peut se situer entre 1000 et 3000 références par langue supportée.

En ce qui concerne la solution adoptée par le site que vous avez évoqué, il peut être plus avantageux de créer un sous site par langue supportée, indépendants entre eux au niveau du code html et php par exemple et travaillant sur une base de données commune. Pourquoi par exemple car plusieurs modèles peuvent s'appliquer comme par exemple des pages html statiques distinctes et un code php commun.

Les avantages et inconvénients
- L'application est plus facilement maintenable, car chaque sous-site peut être géré/maintenu par une équipe différente sans interférences dans leur travail.
- Les pages html contenant le texte spécifique traduit, sort du traitement php et est délivré par un serveur de cache comme nginx par exemple, augmentant la capacité de charge du site et les performances générales.
- Elle permet d'adapter l'expérience d'utilisation à la culture de l'internaute concerné.
- Elle permet de mettre en place une optimisation SEO du site en fonction de la culture, cette optimisation pouvant inclure des règles de rewrite tout aussi spécifiques.
- Si vous êtes seul dans sa maintenance, vous devrez avoir une bonne organisation de votre site au niveau de son arborescence, utiliser des conventions d'écriture (...), bref, cumuler les bonnes pratiques de manière à vous simplifier la tâche dans sa gestion car le nombre de fichiers composant votre site sera plus important.

Pour finir, rien ne vous empêche de cumuler les deux techniques selon vos besoins de production, sans oublier qu'aussi peut se greffer à cela la nécessité de la mise en place d'une gestion de la localisation dans votre modèle de données au sein de votre SGBDR.

++

Dernière modification par Jc (29-12-2013 19:22:13)