1

我目前正在一家公司实习，我的任务是重新评估用于翻译应用程序的工具套件，因为它已成为内部问题。我在网络上到处查看，我的结论是对于这类任务没有适当的文档化端到端工作流程，所以我请求社区帮助我了解他们在该领域看到的情况。

我们当前的流程如下所示：

  • 代码中的 java、属性文件和资源包

  • 基于类从代码中提取键的定制工具。有点笨重，因为它使用类加载，因此有许多实际限制

  • 用于翻译和处理代码修订的定制网络工具

以下是我们正在寻求的一些限制和改进：

  • 我们希望外部翻译人员帮助我们处理我们公司无法处理的其他语言

  • 我们想将元数据添加到翻译键中，例如验证标志、分类数据和描述数据，这些是属性文件无法处理的

  • 我们将有外部翻译人员，并希望能够在可能的情况下使用标准与他们的工具正确集成

这是我在网上找到的：

  • GNU Gettext 的复数处理和上下文消息很好。但是，我们现有的代码是使用键编写的，无法在代码中编写纯英文消息。

  • XLIFF 提供了拥有我们想要添加的所有额外元数据的方法。然而，所有现有的工具要么不完整、有缺陷，要么成本高昂。许多工具都添加了它们自己的元数据，这使得使用 XLIFF 变得复杂。

  • 除了无法在多个 Git 分支上工作之外，Pootle 几乎可以完成我们定制的 Web 工具的工作。

  • Weblate 与 Pootle 类似，具有在多个 Git 分支上工作的能力。但是，更新具有多种语言和多种翻译的项目需要时间。它不能满足我们不断发展的需要。

那么，对于复杂的多模块 Java 应用程序的国际化，您推荐的工具套件是什么？

4

3 回答 3

1

Gettext (.po) 可以通过两个阶段的键来实现：键 -> 英语，英语作为键。可以使用原始密钥进行消歧。可以保留原始密钥。

Gettext 似乎比 XLIFF 使用更广泛 - 但同时我可能错了。

Web 界面很好 - 作为辅助工具。如果提供这样的东西，翻译机构会抱怨。

我不能充分强调文本的交付非常重要，以防止每个翻译人员都必须做额外的工作。几乎可以统一的文本就是这样一个例子。翻译记忆库可能会给出模糊的翻译，但最好在交付翻译之前由专人处理。此外，诸如“从菜单中选择‘处理 thumbleweed’”和“处理 thumbleweed”之类的内容很可能需要翻译负责人，以进行连贯的翻译。XLIFF 可能会提供更多的技术细节，但总的来说，我认为最好让有经验的开发人员来确保开发这个过程。特定术语的通用词汇表。

还可以让应用程序在显示特定语言和键“[key]”之间切换。

于 2013-06-20T15:04:08.967 回答
0

塔皮吉怎么样？不确定它是否能满足您的所有要求，但它可以节省时间。如果您正在使用 Eclipse，或者可以使用它，那么它可能值得一看。从网站：

实现的编辑器基于 Babel Messages Editor Resource-Bundle 编辑器，它将整个 Resource-Bundle 视为正在修改的对象，而不是单个属性文件。此外，Resource-Bundle 视图增加了浏览资源和直接比较不同语言的丰富功能。同时，基于 RCP 和 RAP 的独立应用程序无需编程技能即可转换资源。

于 2013-06-20T14:57:54.220 回答
0

Weblate确实不是最快的导入工具（但在即将发布的 1.6 版本中有许多改进），但文档中有一些提示如何改进这一点。你试过那些吗？

于 2013-07-18T11:40:05.973 回答