私は専門家ではありませんが、ここにいくつかの基本的なものがあります。
文字列が単なるASCII以外のものを処理できることを確認してください
ASCIIに収まらない特定の文字が必要になり、文字列クラスはそれらを禁止する必要はありません。UTF-8はスペース効率が良いため、一般的なエンコードです。何をするにしても、早期にテストし、よじれを取り除きます。
char *
あらゆる場所だけでなく、実際の文字列クラスを使用することは非常に良い考えです。
フォントを忘れないでください。使用しているすべてのフォントに必要な文字があることを確認してください。
コードから文字列を引き出す
これが最も重要なものです。テキストストリングはすべて、スワップアウト可能なデータファイルのコード外に保存されていることを確認してください。このためにパイプラインをセットアップするのは面倒ですが、後で時間を大幅に節約できます。コードに文字列が必要なときはいつでも次のようにシンプルになるように、いくつかのシンプルなAPIが必要になります。
String text = Locale::getString("some unique identifier");
コードで文字列を連結または構築しないでください
テキストが小さな単語からどのように構築されるかについて、仮定を行わないことが重要です。次のような無害なものでも:
String currency = Locale::getCurrencyString() + money.toString();
// creates $123
他の言語では数字の後に通貨記号が配置される可能性があるため、問題です。代わりに、次のようにローカライズされたフォーマット文字列を使用します。
String format = Locale::get("currency format"); // returns "${0}" in English
String currency = String::Format(format, money.toString());
そのようにして、ローカライザーはフォーマット文字列内の単語を再配置できます。
アート、特にビデオに表示されるテキストの量を最小限に抑える
アートアセットをフォークするのは面倒です。一部のUI要素については、少なくとも少し行う必要がありますが、面倒です。FMVの複製は、FMVの複製コピーをレンダリングして保存する必要があるため、大きな苦痛です。
さまざまな言語で徹底的にテストする
ほとんどのコードベースでは、ローカライズAPIを使用する必要があることを言うprintf("Hi there");
かloadTexture("someTexture");
、忘れてしまうのは簡単です。誰かが忘れてしまい、あなたはあなたの第一言語では正しいが、他の言語では間違った何かになってしまいます。これらを見つける唯一の方法は、テスターに非主要言語でテストさせることです。
ローカライズされたテキストの欠落を明らかにする
通常、テキストはサイクルの後半に翻訳されるため、ほとんどの場合、一部の言語のデータはありません。絶えず再翻訳しなくてもコンテンツを繰り返し処理できるため、これは問題ありません。欠点は、物事を見逃し、翻訳を忘れるのが簡単だということです。
できる安価な方法の1つは、欠落しているテキストを「ID #blah blah !!!に必要な翻訳!!!」のように非常に明らかにすることです。ゲーム内で欠落している場合。
最悪の場合の言語に合わせてUIを設計する
異なる言語には、長い単語や短い単語が含まれる傾向があります。英語で美しく見えるUIには、テキストが境界を越えたり、切り取られたり、長い言語で誤って折り返されたりする場合があります。最悪の言語に対応するためにUIを変更する必要があります(またはUIをフォークしますが、おそらくそれはあなたがしたいことではないでしょう)。
面倒なことに、英語は多くの場合、通常ローカライズされた言語の中で最も短い言語です。そのため、おそらくあなたのデザイナーは最良のケースのために不注意に設計しています。設計時に、プレースホルダーに余分な長いテキストを使用するようにします。テキストは、英語よりも約30%長くなる可能性があると想定しています。Google翻訳は、プレースホルダーに適切なテキストを取得するのに適しています。
翻訳の予算時間
通常、テキストの翻訳は、チームが疲れていてあまり気にしないときに遅くなります。それでも、それが起こると、多くのバグが発生します。さらに悪いことに、海外の人にテキストを送信してその変更を待つ必要がある場合、テキストの反復処理の所要時間は長くなる可能性があります。この作業に時間を割り当てます。