PHP Web サイトをさまざまな言語に翻訳する準備を進めており、PHP での gettext サポートは順調に進んでいるようです。
私が見たすべてのチュートリアルでは、英語のテキストをメッセージ ID として使用することを推奨しています。
gettext("こんにちは!")
しかし、それは本当に良い考えですか？マーケティング担当者がテキストを「こんにちは、皆さん!」に変更したいとします。その文字列 (実際にはメッセージ ID) が変更されたので、すべての言語ファイルを更新する必要はありませんか?
「hello.message」のような一般的な ID と、英語の翻訳ファイルを用意した方がよいでしょうか?
うわー、誰も英語をキーにすることを提唱していないことに驚いています。私はいくつかのソフトウェア プロジェクトでこのスタイルを使用しましたが、かなりうまくいきました。コードの読みやすさは素晴らしく、英語の文字列を変更すると、メッセージを再翻訳する必要があることが明らかになります (これは良いことです)。
スペルを修正したり、翻訳を必要としないその他の変更を加えたりするだけの場合は、リソース ファイルでその文字列の ID を更新するのは簡単なことです。
そうは言っても、私は現在、この方法で I18N を新しいプロジェクトに引き継ぐかどうかを評価しているので、なぜそれが良い考えではないのかについていくつかの考えを聞くのは良いことです.
私は、それが「唯一の方法」であると彼が述べているリチャード・ハリソンズの答えに強く反対します。親愛なる質問者、「唯一の方法」は存在しないので、それが唯一の方法であると述べている答えを信用しないでください。
IMHOがリチャーズのアプローチに比べていくつかの利点がある別の方法は次のとおりです。
利点：
welcome_back_1「 」などの意味のある ID を使用しますwelcome back, %1。私は常に英語を「ベース」言語として使用しているため、特定の言語にメッセージ ID がない最悪のシナリオでは、英語にフォールバックします。
英語が変わると ID も変わるため、実際の英語のフレーズをメッセージ ID として使用するのは好きではありません。自動化されたツールを使用している場合、これはあまり影響しないかもしれませんが、私は気になります. 私は単純なコード (msg3975 など) を使用するのは好きではありません。それらには意味がないためです。
ID が英語である理由は、何らかの理由で翻訳が失敗した場合 (現在の言語とトークンの翻訳が利用できない、またはその他のエラー) に ID が返されるようにするためです。もちろん、これは開発者が元の英語のテキストを書いていることを前提としており、ドキュメンテーション担当者ではありません。
また、英語のテキストが変更された場合、おそらく他の翻訳も更新する必要がありますか?
実際には、英語のテキストではなく純粋な ID も使用しますが、デフォルトで英語にするために多くの追加作業を行う必要があることを意味します。
一言で言えば、これをしないでください。
英語の同じ単語/フレーズは、多くの場合、複数の意味を持ち、それぞれが異なる翻訳を意味します。
文字列のニーモニックIDを定義し、英語を単なる別の言語として扱います。
コード内のID番号は、コードの可読性にとって悪夢であるという他のポスターに同意します。
元ローカリゼーションエンジニア
あなた自身の質問にすでに答えていませんか？:)
明らかに、アプリケーションの i18n をサポートする場合は、すべての言語実装を同じように扱う必要があります。文字列を変更する必要があると誰かが判断した場合、すべての言語ファイルに同様の変更を加えます。チェックインを含むメタデータは、すべての言語ファイルを同じ変更にグループ化する必要があります。「デフォルト」の言語が異なる方法で処理されると、保守がより困難になります。
一日の終わりに、翻訳者は座って、すべての言語のテキストを変更できるようにする必要があります (意味が一致するようにするため)。
gettextこれは、適切な答えは、このような文字列を配置する場所の変更されたバージョンを使用することであるように感じさせます
_(id, backup_text, context)
_('ABOUT_ME', 'About Me', 'HOMEPAGE')
コンテキストはオプションです
なぜこのような？他の場所で繰り返される可能性のある英語ではないテキストを一意の ID を使用してシステム内のテキストを識別する必要があるためです。
また、矛盾を減らすために、コード内の同じ場所にバックアップ、ID、およびコンテキストを保持する必要があります。
ID も読み取り可能である必要があり、これは同義語や重複使用 (ID としても) の問題をもたらします。
そのため、最後にコンテキスト変数も追加しました
バックアップ テキストはほとんど何でもかまいません。
「poedit」などの現在の gettext 編集プログラムでは機能しませんが、先頭にアンダースコアを付けずに「t()」のように翻訳用のカスタム変数名を定義できると思います。
gettext もコンテキストをサポートしていることは知っていますが、十分に文書化されておらず、広く使用されていません。
PS私は、良い拡張可能なコードを強制するための最良の変数の順序について確信が持てないので、提案は大歓迎です。
私は、(never のほとんどの値に対して) フリー テキストを何かのキーとして使用したくないとまで言っています。たとえば、SO がクエリ タイトルをこのページのキーとして使用したとします。誰かがリンクした後、タイトルが編集された場合、リンクは無効になります。
あなたの問題は似ていますが、すべてのリンクを更新する責任もあります...
Douglas Leeder が言及しているように、英語と別の言語が混在するインターフェイスは非常に混乱しますが (ただし、少し面白いこともあります)、おそらくやりたいことは英語をデフォルト (バックアップ) 言語として使用することです。
上記の考慮事項に加えて、「キー」(msgid) をソース テキスト (英語) とは異なるものにしたい場合が多くあります。たとえば、HTML ビューでは、アンカー タグの宛先とラベルがユーザーのロケールに依存する [yyyy] と言いたい場合があります。たとえば、ソーシャル ネットワークへのリンクである場合、米国では Facebook ですが、中国では Weibo になります。したがって、MsgIds は socialSiteUrl や socialSiteLabel のようなものになります。
ミックスして使っています。
競合/変更/奇妙な意味を持たないと思われる基本的な文字列については、キーを英語と同じにします。