java - 可以使用 ThreadLocal 来存储请求的 Locale 吗？

Question

我正在对存储在数据库中的相当大的客户端/服务器(HTTP(Hessian)用于通信)应用程序中的用户输入数据进行国际化。用户可以选择他们想要查看的语言，当所请求语言的翻译不存在时，会使用默认语言。

目前一个数据类可能是这样的:

class MyDataClass {
  private Long id;
  private String someText;
  /* getters and setters */
}

国际化之后它看起来像这样:

class MyDataClass {
  private Long id;
  private Set<LocalizedStrings> localizedStrings;
  /* getters and setters */
}
class LocalizedStrings {
  private Locale locale;
  private String someText;
  /* getters and setters */
}

当然，在 MyDataClass 中创建一个委托(delegate) getter 可能会很有趣，它负责在正确的语言环境中获取文本:

public String getSomeText(Locale locale) {
  for(LocalizedString localized : localizedStrings) {
    if (localized.getLocale().equals(locale)) {
      return localized.getSomeText();
    }
  }
}

在我的团队中，有一些担心需要一直传递语言环境，直到他们到达数据类。由于所有这些事情都发生在服务器上，并且对服务器的每个请求都在专用线程中处理，因此有人建议将请求的语言环境存储在 ThreadLocal 对象中并创建向后兼容的无参数 getter :

public String getSomeText() {
  return getSomeText(myThreadLocalLocale.get());
}

然后 ThreadLocal 需要是一个全局变量(在某处是静态的)，或者需要在每次创建实例时将其注入(inject)到 MyDataClass 中(我们使用的是 spring，因此如果我们使数据类由 spring 管理(这我觉得不对))。

使用 ThreadLocal 作为语言环境对我来说有点不对劲。我可以含糊地说我不喜欢 getter 中的无形魔法和对全局变量的依赖(在数据类中!)。但是，对此有“不好的感觉”并不是与同事争论的好方法。为了提供帮助，我需要以下其中一项的答案:

1. 告诉我，出于 X、Y 和 Z 的原因，我感觉很糟糕，但解决方案很好。
2. 给我一些我可以用来与我的同事争论的好的可引用论据，并告诉我如何做得更好(总是传递语言环境或任何其他想法？)

Answer 1

虽然，通常的做法是我不喜欢在应用程序中进行“深度”本地化。

取而代之的是:

public String getSomeText() {
  return getSomeText(myThreadLocalLocale.get());
}

我们这样做:

public LocalizableText getSomeText() {
  return new LocalizableText(resourceBundle, "someText");
}

然后做，例如在 JSP 或输出层中:

<%= localizable.getString(locale) %>

逻辑本身与语言无关。我们有这样的情况，在一些处理之后，应用程序通过邮件发送结果，记录它并以所有不同的语言呈现给网络用户。因此，处理与结果生成以及本地化必须分开。