Quelques considérations :
Qui fera les traductions ? Des personnes également connectées au site ? Une agence de traduction ? Lorsque vous utilisez Gettext, vous travaillez avec des fichiers 'pot' (.po). Ces fichiers contiennent l'ID du message et la chaîne du message (la traduction). Exemple :
msgid "A string to be translated would go here"
msgstr ""Maintenant, cela semble très bien et compréhensible pour quiconque a besoin de traduire cela. Mais que se passe-t-il lorsque vous utilisez des mots clés, comme le suggère Mike, au lieu de phrases complètes ? Si quelqu'un a besoin de traduire un msgid appelé "address_home", il ou elle n'a aucune idée si cela doit être un en-tête "Home address" ou s'il s'agit d'une phrase complète. Dans ce cas, assurez-vous d'ajouter des commentaires au fichier juste avant d'appeler la fonction gettext, comme ceci :
/// This is a comment that will be included in the pot file for the translators
gettext("ready_for_lost_episode");
Utilisation de xgettext --add-comments=/// lors de la création des fichiers .po ajoutera ces commentaires. Cependant, je ne pense pas que Gettext doive être utilisé de cette façon. Aussi, si vous avez besoin d'ajouter des commentaires avec chaque texte que vous voulez afficher, vous a) ferez probablement une erreur à un moment donné, b) tout votre script sera rempli avec les textes de toute façon, uniquement sous forme de commentaires, c) les commentaires doivent être placés directement au-dessus du Gettext fonction, ce qui n'est pas toujours pratique, selon la position de la fonction dans votre code.
Une fois que votre site se développe (encore plus loin) et vos fichiers de langue avec lui, il peut devenir assez difficile de maintenir toutes les différentes traductions de cette façon. Chaque fois que vous ajoutez un texte, vous devez créer de nouveaux fichiers, envoyer les fichiers aux traducteurs, recevoir les fichiers en retour, vous assurer que la structure est toujours intacte (les traducteurs impatients sont toujours heureux de traduire également la syntaxe, ce qui rend l'ensemble du fichier inutilisable :)), et finissez par importer les nouvelles traductions. C'est faisable, bien sûr, mais soyez conscient des problèmes possibles à cette fin avec de grands sites et de nombreuses langues différentes.
Autre option :combinez votre 2e et 3e alternative :
Personnellement, je trouve plus utile de gérer la traduction à l'aide d'un (simple) CMS, de conserver les variables et les traductions dans une base de données et d'exporter vous-même les textes pertinents vers des fichiers de langue :
- ajouter des variables à la base de données (par exemple :id, page, variable );
- ajouter des traductions à ces variables (par exemple :id, varId, langue, traduction) ;
- sélectionnez les variables et les traductions pertinentes, écrivez-les dans un fichier ;
- inclure le fichier de langue pertinent dans votre site ;
- créez votre propre fonction pour afficher un texte variable :
text('var'); ou peut-être quelque chose comme __('faq','register','lost_password_text');
Le point 3 peut être aussi simple que de sélectionner toutes les variables et traductions pertinentes dans la base de données, de les placer dans un tableau et d'écrire le tableau sérialisé dans un fichier.
Avantages :
-
Maintenance. La maintenance des textes peut être beaucoup plus facile pour les grands projets. Vous pouvez regrouper des variables par page, sections ou autres parties de votre site, en ajoutant simplement une colonne à votre base de données qui définit à quelle partie du site appartient cette variable. De cette façon, vous pouvez rapidement afficher une liste de toutes les variables utilisées, par ex. la page FAQ.
-
Traduction en cours. Vous pouvez afficher la variable avec toutes les traductions de toutes les différentes langues sur une seule page. Cela peut être utile pour les personnes qui peuvent traduire des textes dans plusieurs langues en même temps. Et il peut être utile de voir d'autres traductions pour avoir une idée du contexte afin que la traduction soit aussi bonne que possible. Vous pouvez également interroger la base de données pour savoir ce qui a été traduit et ce qui ne l'a pas été. Peut-être ajouter des horodatages pour garder une trace d'éventuelles traductions obsolètes.
-
Accéder. Cela dépend de qui traduira. Vous pouvez encapsuler le CMS avec une simple connexion pour accorder l'accès aux personnes d'une agence de traduction si besoin est, et ne leur permettre de changer que certaines langues ou même certaines parties du site. Si ce n'est pas une option, vous pouvez toujours sortir les données dans un fichier qui peut être traduit manuellement et l'importer plus tard (bien que cela puisse entraîner les mêmes problèmes que ceux mentionnés précédemment). Vous pouvez ajouter l'une des traductions déjà présentes (en anglais ou dans une autre langue principale) comme contexte pour le traducteur.
Dans l'ensemble, je pense que vous constaterez que vous aurez beaucoup plus de contrôle sur les traductions de cette façon, surtout à long terme. Je ne peux rien vous dire sur la vitesse ou l'efficacité de cette approche par rapport à la fonction native gettext. Mais, selon la taille des fichiers de langue, je ne pense pas que ce sera une grande différence. Si vous regroupez les variables par page ou section, vous pouvez toujours n'inclure que les parties requises.
