代码之家 › 专栏 › 技术社区 › corgrath

在源代码中使用本地化文件和硬编码变量的利弊是什么?

variables localization file java

3

corgrath · 技术社区 · 15 年前

文件夹:

变量:

背景:

一些简单的赞成和反对意见:

由于Eclipse正在使用中,所以将未使用的本地化保存为变量比将其保存在文件中更容易跟踪和查找。然而,应用程序的源代码变得更大和臃肿。

更新1:在我的具体案例中,重新编译和部署不是问题,因为这是因为我们有测试阶段,让我们有机会找到打字错误等,因为我们很少需要改变短语,一旦应用程序在生产。

5 回复 | 直到 15 年前

1

3

PeterK 15 年前

在源代码中实现应用程序的本地化有很多缺点——可能最大的缺点是,当你想修复/添加/删除一些本地化时,你必须重新编译它并重新发布一个新版本。使用单独的文件,更新更灵活、更快、更易于维护,当然,其他人可以将本地化添加到您的应用程序中,而无需访问代码。

所以我建议使用单独的文件选项,而不是将其硬编码到应用程序中。

2

1

Sujee 15 年前

我认为在“文件”和“变量”之间没有选择。因为它应该总是“文件”。

a) 易于维护-整个本地化都在一个文件中。

b) 发生更改时不需要重新编译。

3

1

mcandre 15 年前

4

0

JRL 15 年前

如果你要有你的程序的本地化版本,那么很可能你在某个时候需要一个翻译。如果您没有本地化文件,则必须向转换器提供对每个具有字符串资源的源文件的访问权限(您甚至知道它们是什么吗?),然后您需要手动修改源文件,这很容易出错。

5

0

McDowell rahul gupta 15 年前

对于大型软件公司来说,本地化过程传统上是由开发团队中的一个独立小组(通常在不同的国家)执行的。本地化小组经常使用二进制文件—因此要求资源包是独立的人工制品。这个过程的目标之一是不让翻译人员破坏源代码;另一个是不要让程序员破坏字符串。

从您的评论来看,听起来您有一些工具来执行自动字符串提取和插入的替代形式。如果做得好,这可能是一个可行的选择。

关于你的翻译过程我想问的问题:

你有自动提取资源和重写文件的工具吗?
- 任何字符串的剪切和粘贴(尤其是你不能理解的字符串)都很可能是bug的载体。
- 这些工具能区分资源字符串和不可翻译字符串吗?
你给翻译人员一个标准的文件格式,他们有工作的工具?
源代码的大小是否因为添加翻译而显著增加?
- 当涉及到应用程序逻辑时,字符串是你不想看到的杂乱无章的,对于分离逻辑和表示数据有一些说法
如果你增加更多的语言,这种方法会扩展吗?
- 如果编辑器破坏了硬编码字符串,那么硬编码字符串就没有什么意义了
- \uXXXX 逃逸

长寿命的产品可以积累未使用的资源,但我从未见过它成为一个实际问题。如果您对此有强烈的感觉,您可能可以通过扫描源来检测未使用的密钥。