Gettext: Est-ce une bonne idée que l'identifiant du message soit le texte anglais?

Question

Nous nous apprêtons à traduire notre site Web PHP dans différentes langues, et le support de gettext en PHP semble être la solution.

Tous les tutoriels que je vois recommandent d'utiliser le texte anglais comme ID de message, c'est-à-dire.

gettext ("Bonjour!"

Mais est-ce vraiment une bonne idée? Supposons que quelqu'un du marketing veuille changer le texte en "Bonjour à tous!". Dans ce cas, ne devez-vous pas mettre à jour tous les fichiers de langue, car cette chaîne - qui est en réalité l’ID du message - a changé?

Est-il préférable d'avoir un identifiant générique, comme "hello.message", et un fichier de traduction anglaise?

Answer 1

J'utilise des identifiants significatifs tels que " welcome_back_1 " ce qui serait " de retour,% 1 ". etc. J'ai toujours l'anglais comme "base". Dans le pire des cas, lorsqu'une langue donnée ne possède pas d'ID de message, je me rabat sur l'anglais.

Je n'aime pas utiliser les expressions anglaises réelles comme identifiants de message, car si l'anglais change, l'identifiant le change également. Cela ne vous affectera peut-être pas beaucoup si vous utilisez des outils automatisés, mais cela me dérange. Je n'aime pas utiliser des codes simples (comme msg3975) car ils ne veulent rien dire. Il est donc plus difficile de lire le code à moins de laisser des commentaires partout.

Answer 2

Wow, je suis surpris que personne ne préconise d'utiliser l'anglais comme clé. J'ai utilisé ce style dans quelques projets logiciels, et à mon humble avis, cela a plutôt bien fonctionné. La lisibilité du code est excellente, et si vous modifiez une chaîne anglaise, il devient évident que le message doit être pris en compte pour une nouvelle traduction (ce qui est une bonne chose).

Dans le cas où vous ne corrigez que l'orthographe ou apportez une modification qui ne nécessite aucune traduction, il est simple de mettre à jour les identifiants de cette chaîne dans les fichiers de ressources.

Cela étant dit, je suis en train d'évaluer si cette façon de faire sera appliquée à un nouveau projet. Il est donc bon d'entendre quelques réflexions sur les raisons pour lesquelles cela pourrait ne pas être une bonne idée.

Answer 3

Je suis tout à fait en désaccord avec la réponse de Richard Harrisons à propos de laquelle il affirme que c'est "la seule façon". Cher demandeur, ne vous fiez pas à une réponse qui dit que c’est le seul moyen, car le "seul moyen" n'existe pas.

Voici une autre façon pour laquelle IMHO a quelques avantages par rapport à l’approche de Richards:

• Commencez par utiliser la proto-version de la chaîne anglaise en tant qu'original.
• N'affichez pas ces proto-chaînes mais créez un fichier de traduction pour l'anglais sans faille
• Copiez les proto-chaînes dans la traduction du début

Avantages:

• code lisible
• le texte dans votre code est très proche sinon identique à ce que votre vue affiche
• si vous voulez changer le texte anglais, vous ne changez pas la chaîne proto mais la traduction
• si vous voulez traduire deux fois la même chose, écrivez simplement une proto-chaîne légèrement différente ou ajoutez simplement "version pour ceci et cela" et vous disposerez toujours d'un code parfaitement lisible

Answer 4

La raison pour laquelle les identifiants sont en anglais est telle que l'identifiant est renvoyé si la traduction échoue pour une raison quelconque - la traduction pour la langue actuelle et le jeton n'étant pas disponible, ou d'autres erreurs. Cela suppose bien sûr que le développeur écrit le texte anglais original, et non un documentaire.

De plus, si le texte anglais change, il est probable que les autres traductions doivent être mises à jour?

En pratique, nous utilisons également des identifiants purs plutôt que le texte anglais, mais cela signifie que nous devons faire beaucoup de travail supplémentaire pour utiliser l'anglais par défaut.

Answer 5

En un mot, ne faites pas cela.

Un même mot / une même phrase en anglais peut souvent avoir plus d'un sens et chaque traduction une traduction différente.

Définissez des identifiants mnémoniques pour vos chaînes et traitez l'anglais comme une autre langue.

Convenez avec d'autres affiches que les numéros d'identification dans le code sont un cauchemar pour la lisibilité du code.

Ancien ingénieur en localisation

Answer 6

Il y a beaucoup à considérer et répondre n'est pas si facile.

Utilisation de l'anglais courant

Avantages

• Facile à écrire et à lire le code
• Dans la plupart des cas, cela fonctionne même sans exécuter de fonctions de traduction dans le code

Inconvénients

• Les programmeurs impliqués doivent également être de bons rédacteurs:)
• Vous devez écrire des textes exacts et corrects entièrement en anglais, même si la première langue que vous devez exécuter est autre chose (par exemple, nous commençons beaucoup de projets en langue tchèque et nous les localisons plus tard en anglais) .
• Dans de nombreux cas, vous devez utiliser des contextes. Si vous ne le faites pas depuis le début, c'est beaucoup de travail pour les ajouter plus tard. Pour expliquer: en anglais, un mot peut avoir plusieurs significations différentes - et vous devez utiliser des contextes pour les différencier - et ce n'est pas toujours si facile (ordre = ordre de tri, ou bien il peut s'agir d'un bon d'achat).
• Il peut être très difficile de corriger l’anglais plus tard dans le processus. Les corrections apportées aux chaînes sources entraîneront très souvent la perte de phrases déjà traduites. C’est très frustrant de perdre la traduction dans 3 langues différentes simplement parce que vous avez corrigé l’anglais.

Utilisation des touches

Avantages

• Vous pouvez utiliser les fonctions de la plate-forme de localisation même pour la langue anglaise. C'est à dire. nous utilisons la belle plateforme Crowdin. Il existe de nombreux outils pratiques - ou plutôt un flux de travail complet - pour la gestion de la traduction: vote pour différentes traductions, historique de la traduction, glossaires (ce qui permet de garder la traduction / la langue cohérente), correction / validation, approbation, etc. plus lisse.

• Il est beaucoup plus facile d'envoyer des textes en anglais à des fins de relecture, etc. En général, ce n'est pas une bonne idée de laisser les rédacteurs modifier directement votre code:)

Inconvénients

• Configuration de projet plus complexe.
• Plus difficile d'utiliser% d,% s, etc.

Answer 7

N'avez-vous pas déjà répondu à votre propre question? :)

Évidemment, si vous avez l'intention de prendre en charge i18n de votre application, vous devez traiter toutes les implémentations de langage de la même manière. Si quelqu'un décide qu'une chaîne doit être modifiée, vous apportez une modification similaire dans tous les fichiers de langue. Les métadonnées avec l'archivage doivent regrouper tous les fichiers de langue dans le même changement. Si votre " défaut " la langue est gérée différemment, ce qui rend plus difficile sa maintenance.

Answer 8

À la fin de la journée, un traducteur devrait pouvoir s'asseoir et modifier les textes pour chaque langue (afin que leur signification corresponde) sans avoir à impliquer le programmeur qui a déjà fait son travail.

Cela me donne l'impression que la bonne solution consiste à utiliser une version modifiée de gettext dans laquelle vous insérez des chaînes comme celle-ci

_(id, backup_text, context)

_('ABOUT_ME', 'About Me', 'HOMEPAGE')

le contexte étant optionnel

pourquoi comme ça? parce que vous devez identifier du texte dans le système à l'aide d'un identifiant unique, pas du texte anglais qui pourrait être répété ailleurs.

Vous devez également conserver la sauvegarde, l'id et le contexte au même endroit dans votre code pour réduire les écarts.

Les identifiants doivent également être lisibles, ce qui pose le problème des synonymes et de l'utilisation dupliquée (même en tant qu'id), nous pourrions préfixer les identifiants de la manière suivante: "HOMEPAGE_ABOUT_ME". ou "MAIL_LETTER", mais

1. les gens oublient de le faire au début et le changer plus tard est un problème
2. il est plus flexible pour que le système puisse regrouper à la fois par id et par contexte

c'est pourquoi j'ai aussi ajouté la variable de contexte à la fin

le texte de sauvegarde peut être à peu près tout, voire "[ABOUT_ME @ HOMEPAGE texte n'a pas pu être chargé, veuillez contacter exemple@exemple.com]"

Cela ne fonctionnera pas avec les programmes d’édition actuels de gettext tels que "poedit", mais je pense que vous pouvez définir des noms de variable personnalisés pour les traductions, par exemple, "t ()". sans trait de soulignement au début.

Je sais que gettext prend également en charge les contextes, mais il n’est pas très bien documenté ni largement utilisé.

P.S. Je ne suis pas sûr du meilleur ordre de variable pour appliquer un code correct et extensible, les suggestions sont les bienvenues.

Answer 9

J'irais jusqu'à dire que vous ne voulez jamais (pour la plupart des valeurs de jamais) utiliser du texte libre comme clé de quoi que ce soit. Imaginez si SO utilisait le titre de la requête comme clé de cette page par exemple. Si quelqu'un y a un lien et que le titre est modifié, le lien n'est plus valide.

Votre problème est similaire, sauf que vous seriez également responsable de la mise à jour de tous les liens ...

Comme le dit Douglas Leeder, vous voudrez probablement utiliser l'anglais comme langue par défaut (sauvegarde), même si une interface utilisant l'anglais et une autre langue mélangée est extrêmement déroutante (mais légèrement amusante également).

Answer 10

Outre les considérations ci-dessus, il est fréquent que vous souhaitiez utiliser la touche "touche". (msgid) diffère du texte source (anglais). Par exemple, dans la vue HTML, je pourrais vouloir dire [aaaa] où la destination et le libellé de cette balise d'ancrage dépendent des paramètres régionaux de l'utilisateur. Par exemple. ce pourrait être un lien vers un réseau social, et aux États-Unis, ce serait Facebook, mais en Chine, ce serait Weibo. Ainsi, les MsgIds pourraient être quelque chose comme socialSiteUrl et socialSiteLabel.

J'utilise un mélange.

Pour les chaînes de base qui, à mon avis, n’auront pas de conflits / modifications / significations étranges, je ferai en sorte que la clé soit la même que l’anglais