Question

我目前正致力于转换现有的Web应用程序以支持其他语言（即威尔士语）。我建议的方法是将所有显示的文本提取到属性文件中，然后使用JSTL fmt标签访问文本。

我的问题是：这些属性文件应该如何构建？我知道他们需要在Web应用程序的类路径上，但不是直接将它们存储在WEB-INF / classes中，我宁愿在构建步骤中将它们复制到那里。这使我在如何在subversion中存储文件方面具有很大的灵活性。由于它们与jsps紧密结合，因此最好创建一个新的顶级目录（例如资源）并镜像此文件夹下的jsp结构？这会给我一个像

这样的结构

resources/jsp/index.properties
resources/jsp/index_cy.properties

这似乎是一种合理的方法，如果需要它们，它也可以扩展到类的属性文件：

resources/com/mycompany/myapp/CustomObject.properties
resources/com/mycompany/myapp/CustomObject_cy.properties

然后，构建过程可以将所有这些文件复制到WEB-INF / classes中，以便打包到war文件中。

这种方法是否符合行业标准？这是我现有公司的第一个多语言应用程序，因此很可能被用作所有其他应用程序的蓝图。

编辑：有人指出，这种方法可能会导致各种属性文件中出现大量重复的字符串。虽然这是真的，但它只会与jsps中当前存在的重复字符串一样多。是否更好的是从jsp到属性文件的清晰映射，代价是属性文件中的一些重复？

Answer 1

这种方法是否符合行业标准？这是我现有公司的第一个多语言应用程序，因此很可能被用作所有其他应用程序的蓝图。

是的，我认为是。

我相信Maven会创建以下目录结构：

src
  +- main
  |    |- java
  |    |- resources
  +- test
       |- java
       |- resources

这使您可以在代码和单元测试之间进行清晰的分离，然后在Java代码和属性文件等资源之间进行清晰的分离。

Answer 2

有人指出这一点方法可能导致很多各种重复的字符串属性文件。虽然这是真的，但它只会复制多少字符串当前存在于 JSP页面。有一个明确的是更好吗？从jsp映射到属性文件，at 一些重复的成本属性文件？

是的，这总是更好。虽然可以在英语的不同位置/ JSP中“重用”字符串，但在其他语言中仍然可能无法实现。重用本地化字符串还可能在组件之间产生不必要且棘手的依赖关系。翻译人员还需要了解他们在您的申请中翻译的文本的使用情况。

Answer 3

我不确定在资源文件和使用它们的代码文件之间建立过强的连接是个好主意，因为它可能导致不必要的文本重复，可以重复使用。

当文本由第三方翻译时，这尤其成问题，因为当在不同文件中多次出现时，相同的表达式可能会被不同地翻译，这可能会极大地混淆用户。

我将单独构建资源文件，并尝试找到一个本质上有意义的组织，例如： UiLabels.properties，ErrorMessages.properties。

我应该如何构建jsps使用的资源包属性文件？

3 个答案: