国際化されたUIのコロン

gettextまたは同様のフレームワークを使用する場合、UIのラベルを生成するために翻訳文字列に':'（など"Label:"）を含める':'か、UIコード自体に追加する必要がありますか？

コロンは句読点と見なすことができます。これは、ピリオドや疑問符のように、テキストの一部である規則です。

「終了してもよろしいですか？」の疑問符は省略しません。次に、翻訳された文字列に言語依存の方法で質問の属性を追加するコードを記述します。そうすることは、UIコードが不必要にさまざまな言語で文を区切る方法を知る責任を負うことを意味します：メッセージ置換で処理できる責任。

中間の可能性があります。すべてのラベルに英語のコロン機能があるのと同じように、他の言語では、ラベルにも共通の語彙要素があります。その要素が存在する場合、それはおそらく何らかの接頭辞または接尾辞、あるいはその両方です。

装飾なしでラベルを表し、ラベル装飾を追加するためのスキーマを提供する翻訳可能な文字列を追加できます。例として、sprintfUIアプリケーションでC スタイルの書式設定が利用できると仮定します。ラベルを生成するフォーマット文字列の英語版はであり、"%s:"他の一部の言語で動作するため、これもデフォルトになる可能性があります。UIトランスレータは、これ"%s:"を適切と思われるものに置き換えることができます。可能性の1つは、それを単に"%s"（何もしない）に置き換えて、翻訳された文字列テーブル内の各ラベルの完全な装飾表現を指定できることです。したがって、このアプローチは、ラベルを示す字句マーカーを中央に挿入する必要があるいくつかの奇妙な可能性も処理します。

このアプローチは、ラベル文字列の表現のわずかな圧縮、つまり1つのコロン文字の削除のみで達成される場合、価値があるとは思えません。このために100文字の追加コードを記述する必要がある場合、均等にするために100のラベルからコロンを削除する必要があります。これは、費やす時間を正当化することさえ考慮していません。

これにはいくつかの見返りがあるはずです。つまり、アプリケーションはラベルを生成する以外の目的で文字列を使用します（名前でUIフィールドを参照する文を生成するなど）。ダイアログボックスに、テキストを入力するための「ユーザーID：」ラベルがあるとします。「無効なユーザーIDを入力しました」というメッセージを生成する汎用ロジックがある場合。文のボイラープレートテキストとUI要素の名前を組み合わせることで、飾りのない文字列「ユーザーID」を作成し、ラベル作成関数に渡して「ユーザーID：」を生成する必要があります。

多くの言語では、英語の語句からの1対1の翻訳はありませんが、状況に応じた複数の翻訳があります。

翻訳者の生活を楽にするために、文字列にできるだけ多くのコンテキストを提供する必要があります。これには、ラベルのコロンと、それらのラベルが使用されているコンテキスト情報が含まれます。

基本ルールとして、国際化されたUIでは

• パラメータに実際の値を入力する場合を除き、翻訳された文字列は変更しないでください。したがって、事後コロンを追加しないでください。
• パラメータの周りの部分に文字列をカットしません。特に、複数のパラメータを入力する必要がある場合は、少なくとも1つの言語を使用すると、逆の方法でパラメータを使用するほうが自然です。
• 単数形または複数形には注意してください。単数形から複数形を作成する方法や、複数形がいくつあるかという共通のパターンはありません。

私はようやく、i18nファイルで文字列全体（この場合はコロンを含む文字列）を使用することを決定しました。

その理由は、フランス語ではコロンの前にスペースが必要です。したがって、フランス語をエンコードする最良の方法は、コロン（前にスペースを含む）を翻訳文字列に入れることです。

いいえ、フランス語に翻訳しません。しかし、これは一般的な動作規則の例です。UIコードではなく、翻訳文字列にコロンを入れてください。

最適なアプローチは、各ロケールの文字列に文字を埋め込むことです。これにより、ターゲットオーディエンスが期待することについて調査を行った場合、通常はコンテキストが正しいことが保証されます。

通常、各国は句読点のすべての「正しい」場所を指示するスタイルガイドを提供します。そのため、いくつかのWebデザインツールでさまざまな言語の見積もりを処理する方法を考え始めたとき、最初にそのようなスタイルガイドを調べました。

ただし、書面による出版物はスタイルガイドに従う傾向がありますが、オンラインの世界はまったく異なります。通常、多くの英語以外のヨーロッパおよび南アメリカのサイトでは、スタイルガイドのギルメット（«»）とは対照的に、米国スタイルの引用を使用しています。初期のWebに対する米国の支配が、世界中のオンライン言語の使用にどの程度浸透しているかを示しています。

MIT 外国語ニュースおよび新聞：ホームには、数百のオンラインサイトへのリンクがあります。これらを検討することで、ジレンマに対する最善のアプローチを見つけることができました。これは、サイトの所有者がターゲットオーディエンスに適した、最も人気のある19組の引用と埋め込みの引用の組み合わせの 1つを選択する機能を提供することでした。

Chromeは国のスタイルガイドを自動的に使用しようとしますが、幸い、qタグのlang属性でロケールを指定することでオーバーライドできます。これは、現実の世界を考慮に入れず、その実装を理論に依存する自動アプローチの問題を浮き彫りにします。

OPに対して、これらのオンライン新聞サイトを調査して、さまざまな国で実際に使用されているものを確認し、どのアプローチがより一貫した結果をもたらすかを確認できるようにします。

一部の言語では伝統的に英語のコロンに別の文字を使用していますが、オンラインでの使用はそのコロンに慣れているユーザーを対象とする場合があります。また、ロケールによって使用方法が異なり、言語だけでなく、ロケールごとに言語文字列を指定する必要があります。

数年前に自分の国際化を行っていたとき、次のように機能しました。

• ソースコードのメッセージは英語で書かれていました

• メッセージは、翻訳を適用することにより、実行時に翻訳されました（translate（ "string"）または通常は/ "string"としてソースに表示されます）。メッセージと翻訳の事前に作成された辞書があると予想されていました。

• メッセージを翻訳するときに、両端の空白が削除され、末尾の句読点が削除されました。残ったものを翻訳した後、これらは元に戻されました。

• より多くのコンテキストを提供するために、文字列にコメントを追加することがあります。これは、最適な一致を見つけるのに役立つ翻訳プロセスの一部でしたが、コメントは破棄されました。

したがって、「Disk：」などのメッセージで、文字列「disk」は「disquette」などに翻訳され、「Disquette：」として再構成されました。これにより、非常に類似したメッセージの数が減少しました。

これを行ったのは、西ヨーロッパの少数の言語だけでした。おそらくもっとエキゾチックなものには問題があるでしょう。ただし、これにはスクリプトタイプの言語を使用していたため、発生した問題に文字列処理を使用できるようになりました。「G」（Greenの略）を翻訳する必要がある場合、ソースにはleft（/ "Green"と表示されていました）、「vert」などに変換され、「V」に変換されます。

ただし、私は現在のフレームワークとそれらがどのように機能するかについてはよく知りません。これらの種類の問題に対処するためのガイドラインはありませんか？

使用するローカリゼーションシステムに依存する可能性がありますが、他の条件が同じであれば、句読点を追加することは避けます（もちろん、その使用が文法で規定されているフレーズ内にある場合を除きます）。フォントサイズなどのプレゼンテーションであり、実際のコンテンツではありません。したがって、このアプローチではさまざまなものを混合しています。

結局のところ、句読点がある場合とない場合の両方で同じ語句が必要になる場合があります。例えば。"Enter subject:"テキストボックスの横にキャプションを表示できますが"Enter subject"、ウィンドウのタイトルとしても表示できます。

両方を別々に翻訳することは理にかなっていますか？

UIでコロンが実際に見た目が悪く冗長であると判断した場合は、すべての言語バージョンを再翻訳する必要があります。これは少しばかげています。

PS。@bartcによって提供される「基本ルール」は、翻訳された文字列に句読点を含めるかどうかにかかわらず、どちらの方法でも有効です。

PPS。@paulkayukも、（彼のコメントの中で）良い点を提起します-その文化の詳細も考慮に入れられるべきです。あなたがスペイン語で鏡像の疑問符のようなものを持っているなら、もちろんあなたの翻訳にそれらを含めてください。私の答えは、言語にとらわれない統一された句読点を想定しています。これは議論の余地があるようです。

アプリケーション言語ファイルは、単なる単語のダミー翻訳ではありません。これは、単語とその句読点の「プレゼンテーション」を正しい意味のあるコンテキストで翻訳するプロセスです。

Hello?スペイン語は¿Hola?アラビア語ですمرحبا؟。ご覧のとおり、Helloor Holaまたはor مرحباを保存してから、UIでを実行することはできませんthe_hello_text + "?"。正しい出力は生成されません。言語ファイルでは句読点に注意する必要があることは明らかです。つまり、疑問符やコロンを文字列の最後に「追加」することは、GUIの問題ではありません。

句読点とすべてが国際化ファイル内にあり、UIに出力する準備ができている必要があります。

UIが考慮すべき唯一のことは、RTL言語の場合はalign rightのように、このすぐに入手できるテキストの正しい表示です。しかし、これは別の話であり、プレーンテキストの国際化言語ファイル自体とは何の関係もありません。