Java EE i18n和默认项目结构

Question

我是Python Django devel

我想尝试Java一点点.

在django我曾经做过我的翻译,如下:

from django.utils.translation import ugettext_lazy as _

然后,如果在locale/en/django.po文件中的.po文件中指定了转换

_("hello world")

问题1:Java中有类似的东西吗？

我找到了那些:

• gnu.gettext.GettextResource
• java.util.ResourceBundle中
• Spring 3 MVC i18n和i10n

但它们都不是我要找的

我在例子中做了

import java.util.ResourceBundle;
import java.util.MissingResourceException;

public class i18n {
    private static ResourceBundle myResources = ResourceBundle.getBundle("messages");

    public static String _ (String originalStr) {
        try {
            return myResources.getString(originalStr);
        } catch (MissingResourceException e) {
            return originalStr;
        }
    }

}

然后

import static i18n._;

问题2:但是在哪里放置messages.properties文件？

• 我想有一个单独的语言环境目录与这些文件.

• 整个包和子包的翻译

  • 现场/ messages_en_US.properties
  • 现场/ messages_en_UK.properties
  • 现场/ messages_en_AU.properties
  • 等等...

问题3:这部分异常捕获似乎不起作用,你知道为什么吗？

问题4:i18n是否有JavaEE标准？

我认为java EE应该有一个标准化的app目录布局,i18和war目录内容,但是几天和java一起玩弄我发现它非常混乱.因此,我能够在Internet上找到的每个示例开源代码都是完全不同的.从Google Wave Protocol项目开始,以示例小应用程序结束.

问题5:是否有JavaEE编码理念或最佳实践？

我找到了Web应用程序策略,但开发人员似乎并不关心它.测试放置,同样的事情.每个人都有不同的地方.逻辑就像模板中的sql查询一样,WTF ......

Answer 1

放置资源文件没有一个真正的地方; 这通常是应用程序开发人员的决定.将所有文件放在一个标准位置可能在所有体系结构中都没有意义,因此规范不会添加不必要的约束.

究竟如何加载和引用资源包可能会受到您使用的框架的影响.例如,在JSTL应用程序中,您可以使用bundle标记; 在JSF应用程序中,您可以使用loadBundle标记.其他视图技术将定义自己的机制.

一般来说...

ResourceBundle.getBundle从类路径加载资源,因此如果要使用目录,它或其父项之一应该在应用程序类路径上.在WAR中,捆绑包应位于WEB-INF/lib目录或目录中的JAR文件中WEB-INF/classes.

所以,对于捆绑集......

 /WEB-INF/classes/locale/messages.properties
 /WEB-INF/classes/locale/messages_fr.properties
 /WEB-INF/classes/locale/messages_de.properties

...你会通过获取请求Locale并调用来加载bundle :

ResourceBundle.getBundle("locale.messages", locale);

将bundle分配给单个静态变量是一个缺陷:

//BUG! this loads the properties file for the server default locale only!
private static ResourceBundle myResources = ResourceBundle.getBundle("messages");

您必须从请求中获取用户的区域设置.静态分配仅适用于客户端应用程序(如IDE).

请注意,提供messages.properties根基文件作为不受支持的语言环境的回退通常是个好主意.

作为一般的本地化,如果密钥对于捆绑包是唯一的,那么使用原始字符串作为密钥的方法将是正常的.否则,如果由于上下文而导致相同的源字符串被翻译,则会发生冲突.