これで正しい方向に押すだけです。
PHP と JavaScript で多言語 Web サイトを構築しています。javascript (AJAX) を使用してコメント/メッセージをデータベースに送信する場合、ユーザーに成功またはエラー メッセージを表示する必要があります。3 つの異なる言語を使用しているため、コードを使用する各ページにコードを記述し、PHP 言語変数を使用して成功/エラー メッセージを翻訳しています。
すべて正常に動作しますが、ユーザーがページのソースを調べると、Web サイトでさまざまなことに使用している関数の長いリストが表示されます。
すべてをJSファイルに含めたい：
しかし、PHP 言語変数は機能しません。
今頭に浮かぶ唯一のことは、さまざまな言語でさまざまな JS ファイルを作成することです: myjs_en.js
myjs_fr.js
myjs_nl.js
また、3 つのファイルのいずれかを含め、ユーザーが選択した言語を確認します。
または、これに使用できる他のオプションはありますか?
助けてくれてありがとう！
サーバー側から言語サポートを提供するのがおそらく最善でしょう。必要に応じて、Zend_Framework のZend_Translateコンポーネントをスタンドアロン ライブラリとして使用できます。
ドキュメントによると：
「多言語アプリケーションでは、コンテンツを複数の言語に翻訳し、ユーザーの言語に応じてコンテンツを表示する必要があります。PHP はこのような問題を処理する方法をすでにいくつか提供していますが、PHP ソリューションにはいくつかの問題があります。
一貫性のない API: さまざまなソース形式に対応する単一の API はありません。たとえば、gettext の使用法は非常に複雑です。
PHP は gettext とネイティブ配列のみをサポートします: PHP 自体は、配列または gettext のみをサポートします。他のすべてのソース形式は、ネイティブ サポートがないため、手動でコーディングする必要があります。
デフォルトの言語が検出されない: ユーザーのデフォルトの言語は、さまざまな Web ブラウザーの背景についての深い知識がなければ検出できません。
Gettext はスレッド セーフではありません: PHP の gettext ライブラリはスレッド セーフではないため、マルチスレッド環境では使用しないでください。これは、PHP ではなく、gettext 自体の問題によるものですが、既存の問題です。
Zend_Translate には上記の問題はありません。これが、PHP のネイティブ関数の代わりに Zend_Translate を使用することをお勧めする理由です。Zend_Translate の利点は次のとおりです。
複数のソース形式をサポート: Zend_Translate は、PHP でサポートされているものを含むいくつかのソース形式と、TMX および CSV ファイルを含むその他の形式をサポートしています。
スレッドセーフな gettext: Zend_Translate の gettext リーダーはスレッドセーフです。マルチスレッド環境で使用しても問題ありません。
簡単で汎用的な API: Zend_Translate の API は非常にシンプルで、ほんの一握りの関数しか必要としません。そのため、習得が容易で、保守も容易です。すべてのソース形式は同じ方法で処理されるため、ソース ファイルの形式が Gettext から TMX に変更された場合、ストレージ アダプターを指定するコードを 1 行変更するだけで済みます。
ユーザーの標準言語の検出: Zend_Translate は、サイトにアクセスしているユーザーの優先言語を検出して使用できます。
自動ソース検出: Zend_Translate は、複数のソース ファイルを検出して統合し、さらに、ディレクトリまたはファイル名に応じて使用するロケールを検出することができます。"