Re: feature request: string interpolation

[Bruno Haible]

Dear Yaohan Chen,

Thank you for writing up your proposal. I'm not sure I understand it
right:

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

Is there one possible "archer" that can be substituted by the program,
or several different words?

* If there is only a single one, your proposal does not help the
  translators. The translators know how to deal with

   msgid "the archer wears light armor"

  If they have already translated the word "archer" a hundred times,
  they will remember it, or have it in their dictionary, or the
  translation memory will do propose the right translation to the
  translator. Translators know how to deal with this problem.

* If there are several possible substitutions, such as "archer",
  "knight", "king", then the substitution does not work for languages
  with different grammar than English.

> 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.

  This is not the problem. The problem is the opposite: The translations
  know about variations that the English original doesn't know about.
  Flexion depending on gender, definite/indefinite article,
  subject/object distinction are all unknown in the English grammar.

  It is for this reason that the GNU gettext manual, section
  "Preparing Strings", gives advice to mark only entire sentences
  and not to do substitutions.

That said, if substitutions are so essential to your game, and
presenting entire sentences to the translator would lead to huge
repetitive PO files that no translator wants to tackle, then an
alternative is to write a language-dependent flexion engine for each
language. Special code for German, special code for French, special
code for Ukrainian, special code for Turkish, etc. - you'll learn a
lot about the languages and the grammars in the process...

Bruno