10

我正在对存储在数据库中的相当大的客户端/服务器（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 中创建一个委托 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 需要是一个全局变量（在某处是静态的），或者需要在每个实例创建时将其注入 MyDataClass （我们使用的是 spring，所以如果我们让我们的数据类受 spring 管理，我们可以注入它（这感觉不对我））。

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

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

4 回答 4

2

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

除了这个：

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

我们这样做：

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

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

<%= localizable.getString(locale) %>

逻辑本身与语言无关。在某些情况下，经过一些处理后，应用程序通过邮件发送结果、记录并以各种不同的语言呈现给 Web 用户。因此，处理与结果生成和本地化必须分开。

于 2014-02-27T19:52:02.350 回答
1

像您描述的那样使用本地线程是 Web 应用程序中非常常见的模式。以 Spring API 中的此类为例：

org.springframework.web.context.request.RequestContextHolder

使用 servlet 过滤器（或类似过滤器）在本地线程中设置区域设置，然后在服务器完成每个请求后清除区域设置值。不要在每个使用它的地方注入它，而是使用类似于 RequestContextHolder 的静态工厂/访问器方法：RequestContextHolder.getRequestAttributes()。

于 2013-05-30T14:53:05.490 回答
1

这种方法是完全有效的。例如，Spring 通过 RequestContextListener 和 LocaleContextHolder 使用 ThreadLocal使Locale可用。

如果您创建自定义实现，请确保正确处理 ThreadLocal（设置/删除）。

于 2013-05-30T14:55:43.700 回答
1

ThreadLocal 是不好的做法。它是全局变量，任何语言都有很多关于这有多糟糕的文章。Spring 使用它的事实并不能证明使用它是合理的。我喜欢 cruftex 给出的解决方案。避免通过全局变量传递数据。

于 2017-06-25T21:51:50.637 回答