Partial strings offered for translations

It is a bad idea to use partial strings instead of the whole string for translation. I’m referring to pref__unit_minutes and pref__unit_items There are several reasons which I’m not going into details here but will list briefly:

1. not all languages are created equal and what seems to be a prefix in one may be a suffix in other;
2. keeping leading/trailing white-space intact is unreliable and leads to frustrations;

As a rule of a thumb provide translator with whole strings along with the context information (and of course don’t reuse but that’s out of scope for now).

So the best possible way to fix those is to use some placeholder:

• $num minutes for pref__unit_minutes
• $num items for pref__unit_items

Or whatever is available in your environment.

Translators in general are used to the idea of the placeholders and get along quite nicely.

[StoyanDimitrov]

I don’t see an issue with strings defined like this. Quite frankly, I don’t even see an issue in reusing them since I can’t imagine a scenario where there will be ambiguity coming from the context. You may close the issue when you feel ready.

To @X-yl about string reuse. Reusing strings makes translators work harder not easier.

• the conscientious translators check the resulting translation in the UI of the application (as you can imagine it is not always as easy as it seems, but that’s another story). Having one string spread over different parts of the UI is distracting and hampers the translation process;
• there are things called translation memory ™ that help translators in case of already translated equal strings. What we gain here is the freedom to modify the translation to convey better the meaning for the given context;
• different languages have different ways to express seemingly equal concepts. That one greatly depends of the string context;
• as extension to previous point seemingly different source strings may appear equal in translation solely of difference of contexts;
• different languages have or don’t have different structures like genders, cardinals etc that vary differently between seemingly equal contexts;
• probably way more points since it’s the middle of the night here and I’m almost falling asleep.

If I may summarize my whole rant in this few points:

1. Make every possible effort to give translators whole strings as they appear in the UI. That one is crucial for fluent translations. And that goes to full effect for mobile. Especially for mobile!
2. Do not reuse strings. Don’t spare translators - feed them strings! Not all of them will jump from joy, but the one that need to tweak that particular string will be extremely happy to have the freedom to do without the fear of breaking the UI on another place;
3. Context is king. The more information translator is given about the usage of the string the better, the shorter, the meaningful, the natural translation will be. It is important if the string is a button label, a window title, a help text, a description, a link etc. It makes the difference for the one who translates, for one - because she’ll find the string easier in the UI, and secondly - will have more information about the way string is used before heading up to the UI.

[another-sapiens]

@StoyanDimitrov +1 on context. It’s the hardest part to guess in any app, and pretty much the most important. Especially in Spanish, with all the conjugations and whatnot. That’s why it’s always harder to translate a few in-app strings correctly, than the whole readme file.