Pourquoi les gens utilisent-ils de l'anglais simple comme substitut de traduction ?

Question

Il s'agit peut-être d'une question stupide, mais je la pose.

J'ai vu plusieurs projets utilisant une bibliothèque de traduction (par exemple gettext) fonctionnant avec des caractères de remplacement en anglais simple. Par exemple :

_("Please enter your name");

au lieu de placeholders abstraits (ce qui a toujours été ma préférence instinctive)

_("error_please_enter_name");

J'ai vu plusieurs recommandations sur le SO pour travailler avec la première méthode, mais je ne comprends pas pourquoi. Ce que je ne comprends pas, c'est que que faire si l'on doit modifier la formulation en anglais ? ? Car si le texte actuel est utilisé comme clé pour toutes les traductions existantes, il faudrait éditer également toutes les traductions et modifier chaque clé . Ou pas ?

N'est-ce pas terriblement encombrant ? Pourquoi est-ce la norme dans l'industrie ?

Ce n'est certainement pas une normalisation correcte que de procéder de cette manière. Cette méthode présente-t-elle des avantages considérables que je ne vois pas ?

Answer 1

Oui, vous devez modifier les fichiers de traduction existants, et c'est un travail de longue haleine. bonne chose .

Si l'on modifie la formulation anglaise, les traductions doivent probablement être modifiées également . Même si ce n'est pas le cas, vous avez besoin de quelqu'un qui parle l'autre langue pour vérifier .

Vous préparez une nouvelle version et une partie du processus d'assurance qualité consiste à vérifier les traductions. Si la formulation anglaise a changé et que personne n'a vérifié la traduction, cela sautera aux yeux et sera corrigé.

Answer 2

1. La langue principale existe déjà : il n'est pas nécessaire de la traduire.
2. Les traducteurs sont plus à l'aise avec une phrase réelle qu'avec des phrases vagues.
3. Les espaces réservés ne sont que des clés, il est toujours possible de modifier la langue d'origine en créant une traduction. En effet, lorsque la traduction n'existe pas, elle utilise l'espace réservé comme texte traduit.

Answer 3

Nous avons utilisé pendant un certain temps des caractères de remplacement abstraits et il était assez ennuyeux de devoir tout écrire deux fois lors de la création d'une nouvelle fonction. Lorsque l'anglais est le caractère générique, vous écrivez simplement le code en anglais, vous avez un résultat significatif dès le départ et vous n'avez pas besoin de penser à nommer les caractères génériques.

Ma raison d'être serait donc de réduire la charge de travail des développeurs.

Answer 4

J'aime votre deuxième approche. Lorsque l'on traduit des textes, on est toujours confronté au problème suivant homonymes . Par exemple, "ouvrir" peut signifier l'état d'une fenêtre, mais aussi le verbe qui permet d'effectuer l'action. Dans d'autres langues, ces homonymes peuvent ne pas exister. C'est pourquoi vous devriez pouvoir ajouter sens à vos espaces réservés. La meilleure approche consiste à placer cette signification dans votre bibliothèque de textes. Si cela n'est pas possible sur la plateforme que vous utilisez, il peut être judicieux de définir un "langage de développement". Ce langage ajoutera une signification aux entrées de texte telles que : Vous devrez bien sûr faire des efforts supplémentaires pour traduire ce langage en anglais simple (ou dans la langue pour laquelle vous développez). J'ai présenté cette philosophie dans quelques grands projets et à long terme, cela permet d'économiser du temps (et des maux de tête).

Ainsi, si vous développez votre propre bibliothèque de traduction ou si celle que vous utilisez le supporte, vous pouvez faire quelque chose comme ceci :

_(i18n("Please enter your name", "error_please_enter_name"));

Où ?

i18n(text, meaning)

Answer 5

Question intéressante. Je suppose que la raison principale est que vous n'avez pas à vous soucier des fichiers de traduction ou de localisation pendant le développement puisque la langue principale se trouve dans le code lui-même.