i18n - xgettext php




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

Nous nous préparons à traduire notre site web PHP dans plusieurs langues, et le support de gettext en PHP semble être le chemin à parcourir.

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

gettext ("Bonjour!")

Mais est-ce vraiment une bonne idée? Disons que quelqu'un dans le marketing veut changer le texte pour "Salut, y'all!". Alors ne devez-vous pas mettre à jour tous les fichiers de langue parce que cette chaîne - qui est en fait l'ID du message - a changé?

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


J'irais jusqu'à dire que vous jamais (pour la plupart des valeurs de jamais) vous voulez utiliser le texte libre comme clé de n'importe quoi. Imaginez si SO a utilisé le titre de la requête comme clé de cette page par exemple. Si quelqu'un y accède, puis que le titre est édité, 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 Douglas Leeder mentionne, ce que vous voulez probablement faire est d'utiliser l'anglais comme langue (de sauvegarde) par défaut, bien qu'une interface qui utilise l'anglais et une autre langue mélangée soit très confuse (mais légèrement amusante, aussi).


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

Aussi, si le texte anglais change alors probablement les autres traductions doivent être mises à jour?

En pratique, nous utilisons également des ID purs plutôt que du texte anglais, mais cela signifie que nous devons faire beaucoup de travail supplémentaire pour passer en anglais.


J'utilise des identifiants significatifs tels que " welcome_back_1 " qui serait " welcome back, %1 " etc. J'ai toujours l'anglais comme langue de base donc dans le pire des cas, quand une langue spécifique n'a pas d'identifiant de message, je repli sur l'anglais.

Je n'aime pas utiliser les expressions anglaises réelles comme ID de message, car si l'anglais change, l'ID. Cela pourrait ne pas vous affecter 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 signifient rien, donc lire le code est plus difficile à moins de jeter des commentaires partout.


Je suis fortement en désaccord avec la réponse de Richard Harrisons à propos de laquelle il déclare que c'est «le seul moyen». Cher demandeur, ne faites pas confiance à une réponse qui dit que c'est le seul moyen, car la "seule voie" n'existe pas.

Voici une autre façon dont IMHO a quelques avantages par rapport à l'approche de Richards:

  • Commencez par utiliser la version proto de la chaîne anglaise en tant qu'original.
  • Ne pas afficher ces proto-chaînes mais créer un fichier de traduction pour l'anglais
  • Copiez les proto-cordes à la traduction pour le 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 le proto-string mais la traduction
  • Si vous voulez traduire deux fois la même chose, il vous suffit d'écrire une proto-chaîne légèrement différente ou d'ajouter "version pour ceci et cela" et vous avez toujours un code parfaitement lisible

En un mot ne fais pas ça.

Le même mot / expression en anglais peut souvent avoir plus d'une signification, et chacun signifiant une traduction différente.

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

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

Ingénieur de localisation Ex


En plus des considérations ci-dessus, il y a beaucoup de cas où vous voudriez que la "clé" (msgid) soit différente du texte source (anglais). Par exemple, dans la vue HTML, je pourrais dire [yyyy] où la destination et l'étiquette de cette balise d'ancrage dépendent des paramètres régionaux de l'utilisateur. Par exemple, il pourrait s'agir d'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 cordes de base que je ne pense pas avoir de conflits / changements / significations bizarres, je vais faire la clé soit la même que l'anglais.


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

Utiliser un anglais simple

Avantages

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

Les inconvénients

  • Les programmeurs impliqués doivent aussi être de bons rédacteurs :)
  • Vous devez écrire correctement des textes précis en anglais, même dans le cas où la première langue que vous devez utiliser est quelque chose d'autre (c'est-à-dire que nous démarrons des projets en tchèque et que nous les localisons plus tard).
  • Dans de nombreux cas, vous devez utiliser des contextes. Si vous ne parvenez pas à le faire depuis begginig, c'est beaucoup de travail pour les ajouter plus tard. Pour expliquer: En anglais, un mot peut avoir plusieurs formes 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 cela peut être un ordre d'achat).
  • Il peut être très difficile de corriger l'anglais plus tard dans le processus. Les corrections des chaînes sources entraîneront très souvent la perte de phrases déjà traduites. C'est très frustrant de perdre la traduction en 3 langues différentes simplement parce que vous avez corrigé l'anglais.

Utiliser les touches

Avantages

  • Vous pouvez utiliser les fonctions de la plate-forme de localisation même pour la langue anglaise. C'est à dire que nous utilisons la belle plate-forme Crowdin. Il y a beaucoup d'outils pratiques - ou plutôt un workflow complet - pour la gestion de traduction: voter pour différentes traductions, histoire de traduction, glossaires (qui aident à garder la traduction / la langue cohérente), épreuvage, approbation, etc. plus lisse.

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

Les inconvénients

  • Configuration de projet plus compliquée.
  • Plus difficile à utiliser% d,% s etc.




gettext