【问题标题】:Eclipse RCP Internationalization separate pluginEclipse RCP Internationalization 独立插件
【发布时间】:2013-08-12 09:25:28
【问题描述】:

没有教程提供一个具体示例来说明如何创建和使用国际化插件片段。我需要对 plugin.xml 和源代码文件的翻译。试图围绕翻译的去向,以及 i18n 外观的去向。

1. 该片段如何应用于多插件企业应用程序,更重要的是,所有这些插件如何将其字符串外部化到片段中的适当文件夹中?

2. 外部 JAR 呢?该机制如何为外部资源提供翻译支持?

3. 冒着被忽视的风险,是否可以提供viewperspective 的独立翻译?不一定在运行时,因为我知道捆绑包不能动态切换。

【问题讨论】:

    标签: java eclipse eclipse-plugin internationalization rcp


    【解决方案1】:

    我们正在使用http://babel.eclipse.org/babel/ 让人们翻译现有资源。构建过程将所需的语言片段添加到工件中。每个插件都定义了自己的 Messages.properties / Messages.java 文件。 我想,你不能对外部罐子做太多事情。

    例如:

    public final class MyMessages {
      // a string member as you reference it later in the code 
      public static String login_window_user_label;
    
      // static initializer which initalizes the fields in this class
      static {
        NLS.initializeMessages("mymessages", MyMessages.class);
      }
    }
    

    并且(通常在同一个包中)你有一个属性文件,在这种情况下,

    mymessages.properties

    其中包括字符串:

    login_window_user_label = Enter username to login to {0}
    

    在你做的代码中:

    String userNameLabel = NLS.bind(MyMessages.login_window_user_label, Environment.getName());
    

    这就是我们如何使我们的包“可翻译”。构建生成语言片段,babel 服务器实例允许翻译。

    【讨论】:

    • external jars 我正在参考我正在构建自己的 JAR。很多业务逻辑都被打包到一个客户端 jar 中,但是如果不翻译这些资源,i18n 就毫无用处。
    • 所以:1. 您可以使用 Messages/.properties 机制来启用国际化 2. 结合 babel 服务器(和构建过程),您可以创建片段。那还有什么问题呢?
    • JAR 问题已经解决,因为我将与访问器类和消息包一起构建包。
    • Babel 是否只用于翻译 Eclipse.org 项目,还是我可以用它翻译我自己的项目?
    • Afaik 你可以用它来翻译包,不管它们是否来自 org.eclipse 命名空间。不过,您需要自己的 babel 服务器实例。
    【解决方案2】:

    有一些可用的帮助,this article 列出了该过程。它基于 Eclipse 2.0(!),但基本思想仍然正确。 更好的文章是this tutorial by Vogella

    1. 对于您需要翻译的每个插件,您将创建一个插件片段。该片段与一个主机插件相关联,因此您需要多个片段。但是,每个片段都可以包含多种语言。语言由文件夹结构分隔,如Step 5 in the first article

    2. 中所述
    3. 我猜您指的是您自己制作的非 Eclipse Java jar,是吗?如果是这样,那是一个完全不同的过程,最适合带有 Java 标记的单独问题。 Oracle 有一个guide that may help。但请记住,您只需要翻译用户接触到的内容。因此,将所有用户可见的字符串保留在 Eclipse 插件中的重构可能是一个好主意。

    4. 您指的是视图/透视的名称吗?如果是这样,是的。您也可以翻译您在 plugin.xml 中提供的信息。见Vogellas article, chapter 3

    编辑:

    At nr.3 I was referring to choosing which View to translate (e.g. via a view menu), then restart the app, then only the said view should translate

    嗯.. 我想到了一种理论上可行的方法,但我不确定它是否是最佳选择。 所以翻译是基于语言环境的。并给定语言环境,选择特定的翻译。如果不存在适当的翻译,将选择默认值。

    因此,如果您的“视图”菜单要将应用程序的语言环境更改为“us-en-v1”,而您只有一个视图具有“us-en-v1”语言环境的翻译,那将表示将翻译特定视图,但应用程序的其余部分将使用默认值(可能是它们默认返回最接近的翻译,不记得确切)。

    然后,您将为每个视图创建一个新的翻译并为每个视图使用一个独特的语言环境。

    这应该可行,但它滥用了翻译的工作方式,因此可能会导致问题。

    我曾经做过类似的事情,一个应用程序使用相同的语言,但不同的客户有不同的词汇。所以我们使用 i18n 通过定义我们自己的语言环境来使应用程序使用正确的术语。

    【讨论】:

    • 在 nr.3 我指的是选择 View 翻译(例如通过视图菜单),然后重新启动应用程序,然后只有所说的视图应该翻译.
    • @GGrec 编辑了我的回答以回复评论
    • 有趣的想法,每个视图都有自定义区域设置。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-11-15
    • 2015-01-31
    • 1970-01-01
    • 2011-02-20
    • 2014-02-15
    相关资源
    最近更新 更多