3

Play 2.0 / Java でカスタム DateFormatter を作成しました。これは、デフォルトのものは i18n に対応していないように見えるためです (実装の詳細はここでは関係ありません)。

public class DateFormatter extends Formatters.SimpleFormatter<Date>

私のアプリケーション構成には

application.langs="pt-br, en"

ブラウザ オプションで定義された言語には、これら 2 つが含まれます (accept-language)

論理的には、 Lang.preferred(List) は pt-br を優先言語として返します

@Override
public Action onRequest(Request request, Method method) {

    Lang preferred = Lang.preferred(request.acceptLanguages());
    Logger.debug("Preferred language is " + preferred.toLocale());

    return super.onRequest(request, method);
}

しかし（そして悲しいことに）

私のカスタム DateFormatter によって受信されたロケール

@Override
public Date parse(String date, Locale locale)  {
    ...
}

システムの(JVM) ロケールであり、en-US であり、優先されるものではありません。

これは正常ですか？ここで何が欠けていますか?

4

2 に答える 2

2

この回避策を使用できると思います。

リクエストごとに、グローバルインターセプターを使用して、LocaleContextHolderを設定し、リクエストのロケールを設定できます。

public class Global extends GlobalSettings {

    @Override
    public Action onRequest(final Request request, Method actionMethod) {
        LocaleContextHolder.setLocaleContext(new LocaleContext() {
            public Locale getLocale() {
                            Lang preferred = Lang.preferred(request.acceptLanguages());
                return preferred.toLocale();
            }
        });
        return super.onRequest(request, actionMethod);
    }

}

私はそれをテストしませんでした、しかしそれは一撃の価値があります:-)

于 2012-07-16T09:02:13.443 に答える
0

残念ながら、nico ekito が言及したグローバル オーバーライドは、おそらくスレッドが原因で、Play 2.2 では信頼できるソリューションではありません。私の経験では、ロケールが不適切な場合があり、フォーマッタが予期せず動作していました (別の言語でフォーマットしてからコンテキストに設定する場合がありました)。

したがって、基本的にジョン・スミスの最終的な解決策ははるかに信頼できます。formatter メソッドのパラメーターで渡されたロケールを使用する代わりに、そこでコンテキスト ロケールを使用します。 

public Date parse(String date, Locale locale)  {
    Context context = Context.current();
    Lang preferred = Lang.preferred(context.request().acceptLanguages());
    Locale contextLocale = preferred.toLocale()
    ...
}
于 2014-03-28T22:51:32.340 に答える