gettext feature request: string interpolation

[Yaohan Chen]

(I sent this to bug-gnu-gettext, but seeing that it's not on 
http://lists.gnu.org/ , and some gettext posts are posted here, I'm posting 
it here. Sorry if it's posted twice.)

Hello,

I'm suggesting the feature of interpolating strings in the translation text. 
For example, a game has translatable unit names like "archer", and longer 
strings which refer to these names, like "the archer wears light armor", "we 
encountered some archers". My proposal is to enable translators to write such 
things in the .po files:

msgid "archer"
msgstr "archerway"

msgid "the ${archer} wears light armor"
msgstr "ethay ${archer} earsway ightlay armorway"

And the labels will be correctly interpolated with the translated strings in 
the application.

Currently, I see two methods for dealing with such recurring strings:

1. The strings will separate, and the translator is responsible to translate 
each occurrence. This has these disadvantages:
  a) It's difficult to update all occurrences automatically. Search and 
replace is not safe for context-sensitive strings, e.g. "general" may refer 
to a military unit, or be an adjective, and needs to have different 
translations in other languages, in general.
  b) Redundant work and likelihood of typos. Even repeated copy-and-paste can 
still be tedious.

2. The programmer uses programming language features like sprintf to 
interpolate the string, e.g. sprintf("the %s wears light armor", "archer"). 
gettext also provides ways to work around some problems in this approach, 
such as two substrings may be in different orders in another language, and 
the need to alternate spelling for plural forms. However, I see these 
disadvantages: 
  c) sprintf calls and formatting strings for messages may make code less 
readable, and for this reason programmers will less likely use this method. 
  d) The translator does not see which string is interpolated from the .po 
file, but sees placeholders instead. This obstructs the context, making it 
hard to translate some sentences correctly.
  e) gettext has limited ability to properly alter the interpolated string to 
suit various languages' grammars. The programmer therefore needs to be 
cautious about which words/types of speeches can be interpolated.
  f) In some applications such features are not available, for example, a 
mini-language used for a game's campaign files.

I think my proposal, letting gettext to take over the interpolation, solves 
these problems.
  a) People can usually tell which meaning of a word is used, and therefore 
are able to use labels in correct context.
  b) Most translation editors prefill the translation with the original text, 
so the translator doesn't even need to type ${archer} every time, reducing 
work and likelihood of typos. gettext may also check and warn 
about "undefined" labels.
  c,d) "the ${archer} wears light armor" is almost as writable and readable as 
the actual English text, not garbling the code, and is meaningful for the 
translator.
  e) When a substring is translated into a special grammatical form, or 
an "unrelated" word, the translator can just put the literal translation, 
omitting the label. Surely this will introduce maintenance difficulty, but 
it's already there with method 1, or requires too much effort with method 2. 

A problem with my proposal, also applying to method 2, is that form variations 
in English may not have variations in translations. For example, English 
has "we encountered some archers", but some languages don't require plural 
forms. Putting ngettext(..., ..., SOME_MAGICAL_NUMBER) will take advantage of 
the benefits offered by method 2 and my proposal, but is not elegant enough. 
I think a syntax like ${archer:plural} could be introduced to solve this 
problem.

I suspect that similar proposals have already been discussed, or even 
implemented. In that case I apologize, and will be grateful if you could 
point me to the discussions.


Yaohan Chen