Translations dictionaries should use the original strings as keys?

Question

Translations dictionaries should use the original strings as keys?

Navigation

#1 by (3 votes)

13

I have already built a few multilingual systems and sites, and in the tools I knew there seems to be a tendency to use string in the original language of the application (usually English) p>

For example, in a POT file of gettext :

msgid "My name is %s.\n"
msgstr "Meu nome é %s.\n"

In this way, with gettext , a hypothetical code should be changed from

printf("My name is %s.\n", nome);

for

printf(_("My name is %s.\n"), nome);

The gettext even has a tool that scans the code by looking for calls of the _ function, and generates the POT file in the format above, just missing the translated text.

Tutorials of other tools often induce similar practices. But the use of this kind of solution has already caused me many problems. Here in Stack Overflow itself in Portuguese, for example. Whenever any text is changed in the English original, a new pending translation appears no Transifex , without any reference to the previous version of the original or the translation itself. This causes a lot of duplicate work, a lot of inconsistency, and potentially a lot of translated and unused text (because it has been out of date).

It seems to make more sense to use more meaningful names like dictionary keys, for example "CloseLinkText" or something like that. However it is very rare to see anyone recommending this, or even seeing software that uses this type of key.

Questions

Is there any good reason to disseminate this practice of using English strings as keys?
In short, why do so many internationalized systems turn translation work into a nightmare? Is not there a better alternative?

i18n

asked by anonymous 18.05.2015 / 23:01

1 answer

How to make a flex container have the width of the internal divs? Why are floating-point primitives divided or multiplied by certain multiples of 10 displayed in scientific notation?

score 3 · Answer 1

If the language of the program is English, or the developers involved know English well, it seems to me much more productive and clear to use the original message, pretending that other languages do not exist.

In the specific example you gave, you can see the masks, which is important (if the number of masks is greater than the number of additional printf () parameters, the program will break). This is a good reason.

Location / internationalization is always a nightmare. The biggest problems are: size that the translated message will occupy in the user interface, and cultural / jargon differences that the translator can ignore, and if you do not know a little bit of the translated language, you can not even verify.

I do not think POT is the worst scheme, nor does it cause or solve the major problems of location mentioned above. If the original message is changed, at least this is explicit (because it can be automatically detected in the build).

On Android, where it is customary to use R.id labels. instead of the original strings, the opposite problem occurs: someone changes the original message in English, the translations are still valid, but maybe they are no longer suitable for the new size that the new message occupies in the user interface, or maybe the new message is completely different, and keeping the old translations is disadvantageous.

I recognize that one advantage of the label instead of the original English string is when the same message is used in different contexts (menu and title, for example), and the translation may have to be less verbose in the menu because the available space is less.