3 ms·

I've been using gettext for a long time, and used to think like you. But I'm slowly changing my mind. The problem with gettext is that, when you change the Eng

by ngrilly 11y ago

I've been using gettext for a long time, and used to think like you. But I'm slowly changing my mind. The problem with gettext is that, when you change the English text, it also changes the ID of all translations. Moreover, it's often necessary to complete the English text with a short string describing the context, to avoid any confusion between two identical strings in different contexts (for example "open" can have several meaning). When you use a "technical" ID for each translation, you don't have these problems anymore. You can fix a typo in the English translation without checking translations marked "fuzzy" in other languages. You can also include some context in the ID. But the main advantage of using "technical" IDs it that you get a clear separation between the programmer and the product designer. The programmer doesn't need to spend too much time choosing the right wording, and can focus on the code. The product designer can work on the wording independently without bothering the designer. I note that the approach advocated by gettext is very popular among open source projects. It's not a coincidence. Programmers working on open source projects are usually the ones writing the text displayed in the user interface. I note that Java and .Net mainly advocate the "technical" ID approach. It's not a coincidence either. In most IT projects, the text displayed in the user interface is not written by the programmer, but by some project manager or some product designer. It's perfectly possible to have a tool that scans your source code and automatically detects the calls to the translation function, even if you use "technical" IDs. Here is an example: http://glebm.github.io/i18n-tasks/ http://glebm.github.io/i18n-tasks/

level3 11y ago
You hit the nail on the head here. In particular the points about changing the English text and about different contexts resulting in different translations. I also feel that the gettext approach assumes everyone speaks the same base language (namely English), but that's not necessarily true with an international team. Obviously the string IDs still need to be in a common language, but those are simpler to parse and search for than full sentences, especially if the person writing the English text has chosen uncommon words or syntax.
- ngrilly 11y ago
  Thanks! I agree with you that the gettext approach relies on the assumption that everyone speaks the same language. I would add that it also relies on the assumption that every programmer has good writing skills, which is not always the case. In my teams, some programmers are really good at writing code, but not so good at writing a correct English or French sentence. In such a situation, string IDs are better.

by ngrilly 11y ago

level3 11y ago

You hit the nail on the head here. In particular the points about changing the English text and about different contexts resulting in different translations. I also feel that the gettext approach assumes everyone speaks the same base language (namely English), but that's not necessarily true with an international team. Obviously the string IDs still need to be in a common language, but those are simpler to parse and search for than full sentences, especially if the person writing the English text has chosen uncommon words or syntax.

ngrilly 11y ago
Thanks! I agree with you that the gettext approach relies on the assumption that everyone speaks the same language. I would add that it also relies on the assumption that every programmer has good writing skills, which is not always the case. In my teams, some programmers are really good at writing code, but not so good at writing a correct English or French sentence. In such a situation, string IDs are better.