Je développe un site Web en PHP et je voudrais donner à l'utilisateur de passer de l'allemand en anglais facilement.
Donc, une politique de traduction doit être envisagée:
devrais-je stocker les données et sa traduction dans une table de base de données ((1, "Bonjour", "Hallo"), (2, "Bonjour", "Guten Tag"), etc.?
ou devrais-je utiliser les fichiers ".mo" pour le stocker?
De quelle manière est le meilleur?
Quels sont les avantages et les inconvénients?
7 Réponses :
Si vous devez fournir une interface Web pour ajouter / modifier des traductions, la base de données est une bonne idée.
Si, toutefois, vos traductions sont statiques, j'utiliserais GetText ou même un tableau PHP uni.
de toute façon, vous pouvez profiter de zend_translate.
petite comparaison, les deux premiers du tutoriel Zend:
Je recommanderais des tableaux PHP, ils peuvent être construits autour d'une interface graphique pour un accès facile.
Je voudrais aussi suggérer Zend Framework Zend_Translate package.
Le manuel donne une bonne vue d'ensemble sur Comment décider quel adaptateur de traduction utiliser . Même lorsqu'ils ne sont pas en utilisant ZF, cela vous donnera quelques idées sur ce qui est là-bas et ce que les avantages et les inconvénients sont.
Adaptateurs pour Zend_Translate
Après avoir simplement abordé cela moi-même récemment (12 langues et compter) sur un système de production et rencontré quelques problèmes de performance majeurs sur la manière dont je vais suggérer un système hybride.
1) stocker les chaînes de langue et les traductions une base de données - cela facilitera la tâche d'interagir avec / user / supprimer des éléments plus fera partie de vos routines de sauvegarde normales. p>
2) mettant en cache les langues dans des fichiers plats sur le serveur et dessinez ceux-ci comme nécessaire d'afficher sur la page. P>
Les avantages sont nombreux - surtout c'est rapide! Je ne traite pas de connexion au-dessus de la connexion pour MySQL ou des ralentissements de trafic pendant le transfert. (Surtout important si votre serveur DB n'est pas localhost). P>
Cela facilitera également la tâche très facile à utiliser. Stockez les données de votre base de données dans le fichier sous forme de tableau Serialized PHP et GZIP Le contenu du fichier pour réduire le stockage de stockage (cela le rend également plus rapide dans mon analyse comparative). P>
FORT> P>
id string page global 1 hello NULL 1 2 good_morning my_page.php 0
Le garder dans une base de données ralentit réellement la page Charger et réduire les performances. Vous seriez soit mis en cache toutes les cordes qui prendront une mémoire inutile, ou aller chercher une ligne pour chaque chaîne qui provoquerait une refonte de connexion. Les tableaux sont beaucoup plus rapides, plus faciles à gérer et plus faciles à aller chercher.
@HENASRAF - Je suis complètement en désaccord. Avec la mise en cache de fichier, vous bénéficiez d'une base de données pour les mises à jour et les insertions de nouvelles lignes, mais il vous suffit d'interroger les lignes nécessaires la première fois que la page se charge. Une personne prend ce succès et tout le monde profite. De plus, vous vous trompez sur l'hypothèse que vous devez tirer chaque rangée. Vous pouvez interroger un fichier pour chaque page de votre système et ne chargez que les chaînes pour cette page, ce qui rend les fichiers petits. Enfin, faire un lecteur de lecture et un insériité sur un fichier plat gzippé est en réalité plus rapide dans mes repères que d'inclure un fichier de réseau PHP non gzippé.
Hey @shanee, c'est une façon impressionnante de traiter la localisation ... après toutes ces années, pensez-vous toujours que cela soit efficace ou suggéreriez-vous une meilleure approche?
Une note dans MySQL, vous devez utiliser le jeu de caractères UTF8MB4. C'est le seul jeu de caractères qui implémente complètement UTF8. Une autre note @shane avez-vous considéré plus récemment des traductions dans les fichiers .json?
Les tableaux PHP sont en effet le moyen le plus rapide de charger les traductions. Cependant, vous vraiment ne veulent pas mettre à jour ces fichiers à la main dans un éditeur. Cela pourrait fonctionner au début et pour une ou deux langues, mais lorsque votre site pousse que cela devient vraiment difficile à maintenir. Je vous conseille de configurer quelques tables simples dans une base de données où vous conserverez les traductions et construisez une Application simple qui vous permet de mettre à jour les traductions (quelques formulaires pour ajouter et mettre à jour des textes). Quant à la base de données: utilisez une table pour stocker des variables de traduction; Utilisez un autre pour relier les traductions à ces variables. exemple: donc ce que vous faites est: Créez la variable dans la première table
ajoutez des traductions dans la deuxième table (quelle que soit la langue souhaitée)
Après avoir mis à jour les traductions, créer / mettre à jour un fichier de langue pour chaque langue que vous utilisez: Sélectionnez les variables dont vous avez besoin et sa traduction (Astuce: Utilisez anglais s'il n'y a pas de traduction)
Créez un grand tableau avec tout ce genre de choses, par exemple:
Cette configuration est très flexible et avec quelques formes pour mettre à jour les traductions, il est facile de garder votre site à jour dans plusieurs langues. >
Il y a quelques facteurs à considérer.
Le site Web sera-t-il mis à jour fréquemment? Si oui, par qui? vous ou le propriétaire? Combien de données / informations faites-vous affaire? Et aussi ... faites-vous cela fréquemment (pour de nombreux clients)?
Je peux difficilement penser que l'utilisation d'une base de données relationnelle peut couse tous les impacts sérieux de la vitesse, à moins que vous n'ayez de trafic très élevé (plusieurs centaines de milliers de pages par jour).
Si vous le faites fréquemment (pour beaucoup de clients), ne pensez pas non plus: construire un CMS (ou utiliser un existant). Si vous avez vraiment besoin de considérer la vitesse Impact, vous pouvez le personnaliser de manière à ce que, lorsque vous avez terminé avec le site Web, vous pouvez exporter des pages HTML statiques dans la mesure du possible.
Si vous mettez à jour fréquemment, la même chose que ci-dessus s'applique. Si le client doit mettre à jour (et non vous), encore une fois, vous avez besoin d'un CMS. Si vous avez affaire à beaucoup d'informations (grand et de nombreux articles), vous avez besoin d'un CMS.
Dans l'ensemble, un CMS vous aidera à accumuler rapidement la structure de votre site Web, ajoutez du contenu rapide et ne vous inquiétez pas pour ne pas vous inquiéter que sur le code puisqu'il sera réutilisable.
Maintenant, si vous avez juste besoin de créer un petit site Web rapide, vous pouvez facilement le faire avec des tableaux et des datafiles codés en papier.
Mettre à jour. Ce poste de mine manque à une stratégie de mise en cache autre que Static HTML. On pourrait également utiliser Memcache, Redis ou une base de données NOSQL dans certaines circonstances.
Soyez de réaliser que tout le monde du monde lorsqu'il s'agit d'un ordinateur, ils connaissent généralement un anglais commun utilisé dans un ordinateur ou Internet comme à propos de nous, à la maison, envoyer, supprimer, lire plus, etc. Question: Sont-ils vraiment besoin d'être traduits?
OK, honnêtement, une translation sur ces mots n'est en réalité pas «requise», tout est question de «style».
Maintenant, s'il est vraiment voulu, pour les mots communs qu'il n'y a pas besoin d'être changé pour toujours, il est préférable d'utiliser un fichier PHP qui sortit la matrice Lang pour uniquement local et anglais. Et pour certains contenus tels que le blog, les nouvelles et certaines descriptions, utilisez la base de données et économisez autant que la traduction linguistique requise. Vous devez le faire manuellement.
Utiliser et comptez sur Google Translate? Je pense que vous devez penser à 1000 fois. Au moins pour cette décennie.
Dupliquer. Découvrez Stackoverflow.com/Questions/2149116/PHP-Localization-Questio N