Question

D'après votre expérience, est-il préférable d'utiliser 1 fichier de langue ou plusieurs fichiers Langauge plus petits pour chaque langue d'un projet PHP en utilisant l'extension GetText? Je ne sais même pas s'il est possible d'utiliser plusieurs fichiers, il m'est difficile de tester car le serveur cache les fichiers linguistiques.

Je fais plusieurs langues sur un site de réseau social, jusqu'à présent, juste la page d'inscription qui est environ 1 sur 200 pages à aller et il a 35 chaînes de texte à traduire, à ce rythme, le fichier de langue pour chaque langue sera vraiment grand donc Je pensais qu'il serait peut-être préférable de faire différents fichiers linguistiques pour différentes pages ou peut-être des sections comme la section des forums et la section blogs, mais si cela ne fait aucune différence, je ne pourrais pas perdre mon temps pour fabriquer plusieurs fichiers plus petits pour chaque langue.

Je me rends compte que chaque situation est différente et la seule vraie réponse est de la tester, mais j'espère éviter que cette fois et obtenir simplement des options de personnes plus expérimentées, c'est ma première fois à utiliser getText, merci

Était-ce utile?

La solution

J'aurais le module de fichiers linguistiques basé. Avec GetText, vous devez spécifier les paramètres régionaux pour chaque langue. Il conviendrait mieux à disposer de fichiers .po / .mo séparés pour chaque module ou de grandes parties de votre site.

C'est mon opinion. :-)

Autres conseils

J'automatise généralement le processus et j'ai plusieurs langages dans plusieurs fichiers en utilisant une base de données pour modifier le site (à l'aide d'une recherche DB simple). Cela me permet d'embaucher des traducteurs pour venir vérifier facilement la traduction actuelle. Le déploiement en production transforme simplement la base de données en un ensemble de fichiers linguistiques.

D'après l'expérience, je décomposerais les langues sur une base par fichier à mesure que les frais généraux de gestion deviennent lourds et il y a une grande portée pour la duplication et les erreurs.

L'autre avantage, en utilisant une structure de répertoire et une convention de dénomination, la langue correcte peut être sélectionnée par programmation plus facilement que le grand fichier et il est plus facile d'écrire des outils de gestion à un stade ultérieur du projet.

Il vaut également la peine de regarder certains des formats que d'autres personnes utilisent. De nombreux frameworks utilisent ce type de structure, Dashcode, Symfony, Zend, etc. et il existe un format XML XLIFF qui est conçu pour gérer la traduction et s'intègre à de nombreux outils utilisés par les traducteurs.

Plusieurs fichiers sont la meilleure façon de procéder, mais les choses peuvent être désorganisées.

Nous venons de lancer un nouveau service gratuit appelé String qui résout la plupart des problèmes de gestion de plusieurs fichiers linguistiques - comme un camp de base pour la localisation. Vous pouvez soit importer des fichiers existants, soit commencer à partir de zéro avec des touches et des chaînes dans le système. Lorsque vous êtes prêt, vous pouvez à nouveau exporter les fichiers pour exécuter votre application. Il fonctionne avec PHP (Array), PHP (Define), PO, YAML, INI et .Strings Formats.

String vous permet de collaborer facilement avec les traducteurs - vous les invitez simplement à un projet et définissez leurs autorisations linguistiques. Les traducteurs peuvent laisser des commentaires et des questions sur chaque chaîne s'ils ont besoin de plus d'informations - et vous pouvez revenir en arrière en utilisant la fonction d'historique si les choses ne sont pas tout à fait correctes.

Quoi qu'il en soit, suffisamment d'argument de vente! Vérifiez-le à http://mygengo.com/string - Nous aimerions vos commentaires.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top