1

国際化をサポートする必要があるプロジェクトに取り組んでいます。私たちが考えた解決策は次のとおりです。

  1. 言語のプレースホルダーを含む HTML テンプレートを作成します (つまり、home.html)。
  2. 「language_en_GB.json」などのファイルを含む i18n ディレクトリを作成します。
  3. ビルド プロセスでそれらをマージして、出力 HTML を作成します。出力ファイルは、言語ベースのディレクトリ (「views/en_GB/home.html」や「views/fr_CA/home.html」など) に置かれます。

だから基本的にこれ：

<h1>{{i18n_welcome}}</h1>
<h2>{{userName}}</h2>

これと合併：

 {
      welcome:"Welcome!"
  }

ビルドプロセス中にこれになります：

   <h1>Welcome!</h1>
   <h1>{{userName}}</h1>

いくつか質問がありますので、ご意見をお聞かせください。

  1. これは i18n の良いアプローチですか?
  2. その国際化をうまく処理するテンプレートエンジンを知っていますか?
  3. クライアント側の「ベーキング」の解決策はありますか。UI開発者もローカライズできるようにしてほしいです。
4

2 に答える 2

1

ニーズやコードで現在使用しているものに応じて、すぐに使用できる i18n をサポートするフレームワークがいくつかあります。純粋なテンプレート エンジンとして、 VelocityまたはFreemarkerを見ることができます。より完全なフレームワークについては、SpringとSpring の例およびStrutsとStruts2 の例を参照してください。

もちろん、他にも多数のオプションがあります。人々が使用しているのを見た中で最も人気のある 4 つをリストしているだけです。

基本的に、どのフレームワークでも、言語ごとにリソース バンドルを作成します (特定のバンドルの言語を使用して名前が付けられます。例: language_en_GB.properties)。したがって、あなたの思考プロセスはほぼ一致しています。基本的に、html ファイルから始めて、プレースホルダーを含めます。各言語のリソース バンドルで、文字列の想定内容を指定します。その後、フレームワークは、問題の言語に適したリソース バンドルを使用して、その場でマージを行います。

つまり、ほぼ正しい方向に進んでいます。すべては、フレームワークと適切に統合し、それを活用して、ビルド パイプライン中にマージを行うのではなく、マージを行うことが問題になります。

于 2012-07-09T14:20:50.083 に答える
1

あなたは必要な詳細を提供できなかったので、私はあなたの質問に答えることができません. あなたが計画しているのは、別のホイールの再発明のように見えるとしか言えません（ただし、元のものほど丸くはありません）.

特定の i18n ベスト プラクティスがあります。Java の世界では通常、(プロパティ ファイルの形式で) リソース バンドルを使用し、JSTL などのメカニズムを使用して、ページのレンダリング時にそれらを変換することを意味します。別の言語のサポートを導入するために何も再コンパイルする必要がないため、これが最善の方法です。

クライアント側スクリプトのサポートを提供することに関心がある場合は、通常、Web ページからいくつかの配列を書き出し、クライアント側でアクセスすることによって行われます。これが最も一般的な解決策だと思います。もう 1 つの方法は、翻訳を提供し、XHR (つまり AJAX) 経由で読み取る Web サービスを用意することですが、これには問題がある可能性があります。とにかく、何らかの形でサーバー側からクライアント側に翻訳をプッシュする必要があります。
そしてもちろん、リソース バンドルからそれらを読み取る必要があります。

あなたが書いたことから、アプリケーションサーバーに支えられたある種の静的Webページを構築したいようです（したがって、静的Webページのコンパイル）。私の推測が正しければ、正直なところ Java を使用するのは少しやり過ぎです。Joomla、Drupal、jEase などの CMS ソフトウェアを使用することをお勧めします。

于 2012-07-09T14:21:28.623 に答える