国際化とローカリゼーションへの2つのアプローチについてアドバイスを求めています。Spring MVCとDojoを使用するWebアプリがあり、複数の言語をサポートしたいと考えています。だから、私はできました：
<spring:message>プロパティファイルを使用してサーバー側で適切なテキストを生成するために使用します。dojo/i18njsファイルを使用してクライアント側で適切なテキストを選択するために使用します。そしてもちろん、2つの任意の組み合わせもオプションです。
では、各アプローチの長所と短所は何ですか？どちらを使用しますか？
これら2つのアプローチの組み合わせが唯一の合理的な答えです。基本的に、サーバー側に固執し、本当に必要な場合にのみクライアント側を実行する必要があります（動的に作成されたコントロールがあるなど、他の方法はありません）。
長所と短所？クライアント側の文字列の外部化の主な欠点は、すべてを正しく翻訳できないことです。それは文脈のせいです。同じ英語の用語は、文脈に応じて異なる方法で翻訳される場合があります。
同時に、メッセージをフォーマットする（メッセージタグにパラメータを追加する）必要があることがよくあります。これは、通常のJavaでは。を呼び出すことによって行いますMessageFormat.format()。理論的には、クライアント側でそれを行うことができますが、控えめに言ってもこれは危険です。元のメッセージ部分（日付、一部のデータソースなど）にアクセスできなくなり、翻訳の正確性が損なわれる可能性があります。
日付や数値などのフォーマットは、クライアント側でより面倒です。DojoまたはjQueryGlobalizeを使用して可能ですが、結果が期待どおりにならない場合があります。しかし、Springにはとにかく日付のフォーマットに問題があります（デフォルトのローカル日付/時刻指定がないため、short、medium、long、fullからしか選択できません。これは私にはまったく役に立ちません）。
別の問題は、複数形（英語以外）の処理である可能性があります。信じられないかもしれませんが、言語には複数形があり（数量によって異なります）、そのために翻訳が異なる場合があります。Dojoはそれをまったく処理していないと思います（しかし、私はそれを評価してからしばらく経ちましたが、私は間違っているかもしれません）。Springもそれを処理しませんが、 ICUの PluralRulesに基づいてカスタムソリューションを構築することができます（または、フォーマットを習得するのが難しく、同時に翻訳者を殺したい場合は、PluralFormat）。
簡単に言うと、I18nを正しく実行することは決して簡単なことではなく、サーバー側でより良いサポートを得ることができます。
ところで。Dojoはかなり「重い」もので、ライブラリ自体は1MBを超えていたのを覚えています...ロードに時間がかかり、アプリケーションが他のアプリケーションに比べて遅いように見えるかもしれません...それが理由の1つで、DojoではなくGlobalizeをお勧めしました私たちのプロジェクトのために。それほど多くの機能はないかもしれませんが、少なくとも軽量のようです。