Why do people use translation placeholders instead of plain English?
up vote
1
down vote
favorite
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.
- I wouldn't use plain English to reduce the number of files to be loaded. This seems obviously wrong.
- JSON? What's wrong with PO/POT? There are so many tools for translators already.
- 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?
- It seems easier to me that devs can focus on getting the English text right and translators getting the other languages right.
- 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.
gettext i18next react-intl react-i18next
asked Nov 10 at 6:53
Cecile
420310
add a comment |
up vote
1
down vote
favorite
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.
- I wouldn't use plain English to reduce the number of files to be loaded. This seems obviously wrong.
- JSON? What's wrong with PO/POT? There are so many tools for translators already.
- 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?
- It seems easier to me that devs can focus on getting the English text right and translators getting the other languages right.
- 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.
gettext i18next react-intl react-i18next
asked Nov 10 at 6:53
Cecile
420310
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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.
- I wouldn't use plain English to reduce the number of files to be loaded. This seems obviously wrong.
- JSON? What's wrong with PO/POT? There are so many tools for translators already.
- 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?
- It seems easier to me that devs can focus on getting the English text right and translators getting the other languages right.
- 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.
gettext i18next react-intl react-i18next
asked Nov 10 at 6:53
Cecile
420310
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.
- I wouldn't use plain English to reduce the number of files to be loaded. This seems obviously wrong.
- JSON? What's wrong with PO/POT? There are so many tools for translators already.
- 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?
- It seems easier to me that devs can focus on getting the English text right and translators getting the other languages right.
- 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.
gettext i18next react-intl react-i18next
gettext i18next react-intl react-i18next
asked Nov 10 at 6:53
Cecile
420310
asked Nov 10 at 6:53
Cecile
420310
edited Nov 11 at 12:53
asked Nov 10 at 6:53
Cecile
420310
asked Nov 10 at 6:53
Cecile
420310
asked Nov 10 at 6:53
Cecile
420310
420310
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
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.
answered Nov 10 at 6:59
talkingtoaj
324111
3
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 at 7: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 at 7: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 at 16:50
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
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.
answered Nov 10 at 6:59
talkingtoaj
324111
3
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 at 7: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 at 7: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 at 16:50
add a comment |
up vote
2
down vote
accepted
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.
answered Nov 10 at 6:59
talkingtoaj
324111
3
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 at 7: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 at 7: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 at 16:50
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
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.
answered Nov 10 at 6:59
talkingtoaj
324111
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.
answered Nov 10 at 6:59
talkingtoaj
324111
answered Nov 10 at 6:59
talkingtoaj
324111
answered Nov 10 at 6:59
talkingtoaj
324111
answered Nov 10 at 6:59
talkingtoaj
324111
324111
3
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 at 7: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 at 7: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 at 16:50
add a comment |
3
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 at 7: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 at 7: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 at 16:50
3
3
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 at 7:10
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 at 7:10
1
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 at 7:27
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 at 7: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 at 16:50
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 at 16:50
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53236698%2fwhy-do-people-use-translation-placeholders-instead-of-plain-english%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
