9

大多数人都会同意，将现有应用程序国际化比从头开始开发国际化应用程序更昂贵。

这是真的吗？或者当你从头开始编写一个国际化的应用程序时，做 I18N 的成本只是被分摊在多个小任务上，没有人觉得他肩上的国际化任务的全部重量？

你甚至可以声称一个成熟的应用程序有许多在项目历史期间被删除的 LOC，如果事后考虑国际化，它们不需要 I18Ned，但如果项目国际化，它们就应该是 I18N从一开始。

那么，您是否认为从今天开始的项目必须国际化，或者该决定是否可以根据软件所享有的成功（或不成功）和需求的地理分布推迟到未来。

我不是在谈论操纵 unicode 数据的能力。您可以在大多数主流语言、数据库和库中免费使用。我说的是支持您自己的软件用户界面以多种语言和区域设置。

4

10 回答 10

14

“当你从头开始编写一个国际化的应用程序时，做 I18N 的成本是……摊销的”

然而，这还不是全部。

追溯追踪发给用户的每条消息——在某些情况下——是不可能的。

不难。不可能的。

考虑一下。

theMessage = "Some initial part" + some_function() + "some following part";

您将很难找到所有这些情况。毕竟，some_function只是返回一个字符串。您不知道它是数据库密钥（从未向任何人显示）还是必须翻译的消息。当它被翻译时，语法规则可能会揭示一个由三部分组成的字符串连接是一个愚蠢的想法。

您不能简单地将每个字符串值函数 GREP 为包含必须翻译的可能 I18N 消息。您必须实际阅读代码，并可能重写函数。

显然，当some_function它有任何复杂性时，你会很难理解为什么你的应用程序的一部分仍然是瑞典语，而其余部分却成功地通过 I18N 翻译成其他语言。（不要特别挑瑞典人，用任何不同于最终部署的开发语言替换它。）

当然，更糟糕的是，如果您使用 C 或 C++ 工作，您可能会在预处理器宏和正确的 C 语言语法之间存在一些分歧。

而在动态语言中——代码可以在运行中构建——你会被无法确定所有代码的设计瘫痪。虽然动态生成代码是一个坏主意，但它也使您无法追溯 I18N 工作。

于 2010-02-25T12:46:32.227 回答
5

我将不得不不同意将其添加到现有应用程序而不是从头开始添加新应用程序的成本更高。

  • 在应用程序变得“大”之前，很多时候不需要 i18n。当你做大时，你可能会有一个更大的开发团队来致力于 i18n，这样它的负担就会减轻。
  • 您可能实际上并不需要它。当您没有客户需要时，许多小型团队会努力支持国际化。
  • 国际化后，增量更改会更加耗时。这不会花费很多额外的时间，但是每次需要向产品添加字符串时，都需要先将其添加到捆绑包中，然后再添加引用。不，这不是很多工作，但这是努力并且确实需要一些时间。

我更喜欢“当我们遇到它时越过那座桥”，只有当你有付费客户寻找它时才国际化。

于 2010-02-25T12:56:13.333 回答
1

是的，将现有应用程序国际化肯定比开发从一开始就国际化的应用程序更昂贵。它几乎从来都不是微不足道的。

例如

Message = "Do you want to load the " & fileType() & " file?"

没有一些代码更改就无法国际化，因为许多语言都有语法规则，如性别一致。您通常需要不同的消息字符串来加载每种可能的文件类型，这与英语中可以将子字符串连接在一起时不同。

还有许多其他类似的问题：您需要更多的 UI 空间，因为某些语言需要比英语更多的字符来表达相同的概念，东亚地区需要更大的字体，您需要在用户界面中使用本地化的日期/时间，但可能是英语美国在与数据库通信时，您需要使用分号作为 CSV 文件的分隔符，字符串比较和排序是文化、电话号码和地址...

那么，您是否认为从今天开始的项目必须国际化，还是可以根据软件的成功（或不成功）和需求的地理分布将该决定推迟到未来？

这取决于. 具体项目国际化的可能性有多大？快速获得第一个版本有多重要？

于 2010-02-25T13:13:15.540 回答
0

我不能说什么是昂贵的，但我可以告诉你，一个干净的 API 可以让你以非常低的成本国际化你的应用程序。

于 2010-02-25T12:57:14.707 回答
0

如果您真的认为您“免费”获得了“unicode 处理”，那么当您尝试时，您可能会有惊喜。

除非您使用已证明 i18n 能力超越具有 ANSI 或非常相似字符集的语言的框架，否则您会发现一些小问题和更多重大问题，其中 unicode 处理不太正确，或者根本不可用。即使使用相对常见的语言（例如德语），您也可能会遇到缩减或扩展不支持 unicode 的字母数和 API 的困难。

然后想想具有不同阅读顺序的语言！

这是您应该从一开始就真正计划好的原因之一，并在您计划支持的语言集上测试要销毁的东西。

于 2010-02-25T13:01:22.760 回答
0

i18n 和 l10n 的概念比仅仅在某些语言之间来回翻译字符串更广泛。

示例：考虑用户输入的日期和时间。如果您在设计时没有考虑国际化

a) 用户界面和

b) 存储、检索和显示机制

当您想要启用其他输入方案时，您将度过一段非常糟糕的时光。

同意，在大多数情况下，首先不需要 i18n。但是，这就是我的观点，如果您不考虑i18n 必须触及的某些领域，您会发现自己最终会重写大部分原始代码。然后，添加 i18n比事先花一些心思要贵得多。

于 2010-02-25T13:06:29.773 回答
0

看起来可能是一个大问题的一件事是不同语言的消息的不同字符数。我在 iPhone 应用程序上做了一些工作，尤其是在小屏幕上，如果您为包含 10 个字符的消息设计 UI，然后您尝试国际化，发现您需要 20 个字符才能显示相同的内容，您现在必须重做您的 UI以适应。即使使用桌面应用程序，这仍然是一个大型 PITA。

于 2010-02-25T13:09:50.243 回答
0

这取决于您的项目以及团队的组织方式。

我参与了一个网站的国际化工作，它是一名全职开发人员一年，可能需要大约 6-8 个月的兼职时间让我在需要时处理安装影响（重组文件等），以及其他当他们的项目需要大量重构时，开发人员会不时参与进来。这是在 v3 的应用程序中。

所以肯定很贵。你要问的是，从一开始就提供本地化系统的成本是多少，以及这将如何影响项目的早期阶段。您的 v1 项目可能无法承受因仓促设计的国际化框架问题而导致的延迟和挫折，而拥有广泛客户群的稳定 v3 项目可能有资本投资于正确地做这件事。

它还取决于您是否要国际化包括日志消息在内的所有内容，或者只是 UI 字符串，以及这些 UI 字符串有多少，以及您可以进行本地化的人员和随之而来的 QA，甚至是什么语言您想支持 - 例如，您的系统是否需要支持 unicode 字符串（这是亚洲语言的要求）。

于 2010-02-25T13:40:22.193 回答
0

并且不要忘记，更改数据库后端以支持国际化数据也可能代价高昂。当您已经有 20,000,000 条记录时，只需尝试将该 varchar 字段更改为 nvarchar。

于 2010-02-25T18:40:22.347 回答
0

我认为这取决于一种语言。每个 j2ee(java web) 应用程序都是 i18n，因为它非常简单（甚至 IDE 都可以为您提取字符串，您只需命名它们）。

在 j2ee 中，稍后添加它更便宜，但是文化是尽快添加它们。我认为这是因为 j2ee 使用了很多开源并且几乎所有开源库都是 i18n。这对他们来说是个好主意，但对大多数 j2ee 应用程序来说不是。大多数企业应用程序仅适用于说一种语言的公司。

另外，如果你有糟糕的测试人员过早发布，他们会给你关于标签和翻译的错误报告（我只见过一次不是由开发人员完成的翻译）。测试人员完成后，您将拥有具有出色 i18n 支持的错误应用程序。但是，用户切换语言并查看他们是否可以使用它可能会很有趣。但是，使用您的应用程序对他们来说只是无聊的工作，因此他们甚至不会这样做。i18n 的唯一用户是测试人员。

j2ee 文化中不存在奇怪的字符串连接，因为您知道有一天有人可能想要使其成为 i18n。唯一的问题是从 html 模板中提取标签。

于 2010-02-25T19:23:50.310 回答