2010-10-21 7 views
1

J'ai récemment rejoint une équipe qui était auparavant un one man show pour maintenir et développer le site PHP-mysql d'une entreprise. La méthode de localisation actuelle est, pour chaque section du site, un fichier se terminant par _en.php et _fr.php qui contient de longues listes de mêmes variables nommées avec du texte dans la langue appropriée. En haut de chaque page de contenu, la langue de l'utilisateur est déterminée, puis le fichier «dictionnaire» approprié est chargé. J'essaie de promouvoir comme alternative d'utiliser une table db comme (id, code, en, fr) et une fonction pour rechercher la traduction correcte dans la page en cours.Quelle est la meilleure méthode de localisation de site?

Mon patron me dit que les avantages de la première approche sont les suivants: avoir un contexte pour chaque traduction, et ayant les traductions sous contrôle de source

Ses préoccupations avec mon approche proposée sont le manque de ces choses, et doesn Je n'aime pas l'idée d'avoir deux systèmes de traduction sur le site. Mes préoccupations sont que, ce sont des données dans un fichier de code, qui m'a été enseigné comme une mauvaise idée. Pour rechercher une chaîne, vous devez utiliser un outil de recherche ide, et donc je ne vois pas comment un programmeur ne serait pas à l'aise de les éditer.

Alors, son approche est-elle meilleure? Est-ce que le mien est meilleur mais seulement marginalement et ne vaut pas la peine de bercer le bateau? Est-ce que le système actuel est un désastre qui attend de se produire que je ne devrais pas lâcher?

Répondre

2

Je pense que pour les choses d'interface (nom, prénom, texte dans les boutons etc ...) est plus naturel d'utiliser un fichier de ressources. En .NET, nous utilisons .resx, en PHP, un fichier d'inclusion est suffisant.

Pour utiliser une archive avec un include ne consomme pas beaucoup de ressources, il s'agit d'analyser un XML. Si nous parlions de gros textes, je les mettrais dans un db avec un code différent, simplement parce que normalement j'aurais un backoffice pour modifier ces contenus, pas pour des problèmes de performances. N'oubliez pas que l'accès à la base de données est également consommé, cela dépend du nombre d'utilisateurs.

Questions connexes