- 本質的な概念。
- 使用する文字列と文字のデータ型は?
- 入力と出力に使用するライブラリ/ルーチンは?
- どのような変換メカニズム (これは gettext や libintl になると思いますか)?
- 移植ガイドライン?
標準 C/C++ ライブラリは、上記の問題にどこまで対応できるでしょうか? ソフトウェアをプラットフォーム間でどの程度移植可能にできますか? この分野の標準/ベストプラクティスは何ですか?
標準 C/C++ ライブラリは、上記の問題にどこまで対応できるでしょうか? ソフトウェアをプラットフォーム間でどの程度移植可能にできますか? この分野の標準/ベストプラクティスは何ですか?
このデータ型は異なる環境では同じサイズではないため、wchar_t
orの使用は避けます。std::wstring
たとえば、Windows では 16 ビットですが、Unix システムでは 32 ビットです。これはトラブルを求めます。
Unicode 標準 (最低限) を自分で実装する時間/リソースがない場合はstd::string
、UTF-8 文字のコンテナーとして使用することをお勧めします。ただし、UTF-8 の場合、マルチバイト エンコーディングを処理する必要があることに注意する必要があります (1 文字が 1 バイト以上に対応する場合があります)。
ライブラリに関しては、 ICUを考慮する必要があります。これにより、エンコーディング間の変換、大文字/小文字/タイトルの大文字小文字への変換などが可能になります。ロケールにも役立ちます。
Mariusが指摘したように、翻訳は通常、指定したキー (文字列、ID、またはその他のもの) でテーブルを検索し、最終的に翻訳文字列を返す関数を介して行われます。
すべてのプラットフォームで同じデータ型を使用することに固執すれば、移植はスムーズに進みます。ICUはクロスプラットフォームのライブラリであることは言うまでもありません。
wchar_t
またはstd::wstring
あなたの友達です。wcscpy()
またはのような適切なワイド文字関数およびオブジェクトでそれらを使用しますstd::wcout
。
また、ロケールごとに文字列テーブルを使用し、そのような関数は現在のロケールの文字列テーブルでstd::wstring getLocalizedString(MY_MESSAGE)
定数を検索します。MY_MESSAGE
文字列テーブルをどのように実装するかはあなた次第です。そのようなものを外部ファイルに保存することは常に良い考えです。