1

Yes, this is the exact opposite question than: Why do people use plain english as translation placeholders?

I used the standard gettext way for translation all the time but now that I'm doing frontend I realized that not only most libraries are using keys/placeholders but this is sometimes recommended (see i18next) over using plain English.

I haven't work much with placeholders but I find it difficult because:

  • you have to invent unique placeholder names all the time, you need conventions
  • maybe you want to reuse the same placeholder name so you have to find an existing one that matches what you are translating
  • is it better to have all translations scoped per module or to have shared translations? I'm not sure

According to the doc of i18-next, it is recommended to use placeholders because:

While this works and might reduce files to load it makes the management of translations a lot harder as you will need to update changes to fallback values in code and json files.

  1. I wouldn't use plain English to reduce the number of files to be loaded. This seems obviously wrong.
  2. JSON? What's wrong with PO/POT? There are so many tools for translators already.
  3. If a wording needs to be changed, all translations should be reviewed, so I guess it's kinda "good" that it would break the old translations, right?
  4. It seems easier to me that devs can focus on getting the English text right and translators getting the other languages right.
  5. I really don't see how it's a lot harder to use plain English. A real life example would be great.

My guess is that there are pros and cons to both methods but I don't see the pros with placeholders so I would like to understand.

Cecile
  • 1,553
  • 1
  • 15
  • 26

1 Answers1

2

I think it only comes down to the previous assumption that a fixed placeholder id means you can later finesse the English translation string without breaking the placeholder's connection to completed foreign translations.

However, I am of the same opinion to you - plain English is better, and if the English changes then certainly the foreign translations also need to be checked whether they too need updating.

Conventions can be wrong.

talkingtoaj
  • 848
  • 8
  • 27
  • 4
    To add some detail to that first paragraph: if your programmers aren’t native English speakers/do not speak the language the app is primarily in/simply aren’t good writers, and you haven’t worked out the exact wording beforehand, using “meaningless” placeholders may work better in your workflow. – deceze Nov 10 '18 at 07:10
  • 1
    True - however for a non-native English programmer, the English will likely have to be worked out before other translations are added, in which case we could refactor the placeholders before translation work begins – talkingtoaj Nov 10 '18 at 07:27
  • Thank you for your answer. I was hoping to get the opinion of a true believer of placeholders :D but your argument is relevant and seems to be the one that make most sense imho :) – Cecile Nov 16 '18 at 16:50