しばしば二つの英語文字列が全く同じであるにもかかわらず、違った文脈において違った意味を持つことがあります。ですから、それらはおそらく翻訳されれば全く同じにはならないでしょう。ところが英語文字列は探索のキーとして使われますから、これは問題になります。

このような場合は文字列に追加の文字を加えてください。例えば、ただの"jumps"の代わりに"jumps[noun]"と"jumps[verb]"を使い、gettext呼び出しを行った後で追加の文字を削ってください。追加の文字を加えるときはそのことを翻訳者がわかるようにコメントもすべきです。このようなコメントを.poファイルの中で見かけるようになるでしょう:

// note to translators: don't translate the "[noun]" part - it is
// just here to distinguish the string from another "jumps" string
text = strip(gettext("jumps[noun]"), "[noun]");

Cプログラマならばsprintf()を使って文字列を構成・結合するでしょう。C++ではstream系が好まれますが、残念なことにそのアプローチは翻訳を難しくしてしまいます。なぜなら、文章を細かく分けて個別に翻訳したのでは、翻訳者はそれらを言語固有の文法に沿ったものに並べ替えることができなくなってしまうからです。

例えば、次のコードは問題となります:

std::cout << _("Current amount: ") << amount
          << _(" Future: ") << future << std::endl;

label.set_text(_("Really delete ") + filename + _(" now?"));

ですから、なるべくこのような状況は避けるか、Cスタイルのsprintf()に変更してください。もうひとつ使えそうな方法としてはcompose libraryがあり、これは次のような文法をサポートしています:

label.set_text(compose(_("Really delete %1 now?"), filename));

文字列が翻訳されたときにどれくらい場所をとるのか知ることは出来ません。非常によくあるケースでは元の英語文字列の二倍になります。幸運なことに、gtkmmのほとんどのウィジットは実行に要求されたサイズまで拡大されます。

暗号的なアクロニム、俗語、ジャーゴンの使用は避けるべきです。それらは普通、非常に翻訳しづらく、しばしば英語話者でさえ理解しづらいものになるからです。例えば、"app"よりは"application"としたほうがいいでしょう。

現在のところ、gettextはソースコードで非ASCII文字をサポートしていません（つまり、全ての文字は127以下のコードです）。ですから、例えばコピーライト記号(©)は使うことができません:

これをうまく行うには、ソースコード中のその文字列の直前にコメントを書き、使える場合は特殊文字を使ってくださいと翻訳者へ指示するのがよいでしょう。それから、英語ユーザーのためにアメリカ英語の翻訳en_US.poを作成し、その中で特殊文字を使ってください。