以后国际化真的更贵吗？ [关闭]答案

【问题标题】：Is internationalizing later really more expensive? [closed]以后国际化真的更贵吗？ [关闭]
【发布时间】：2010-02-25 12:42:04
【问题描述】：

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

这是真的吗？或者，当您从头开始编写国际化应用程序时，I18N 的成本只是分摊在多个小任务上，没有人能感受到国际化任务的全部重量？

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

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

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

【问题讨论】：

为什么要关闭投票？这是一个有趣的问题，肯定与编程有关。
它可能已被投票关闭，因为它不是社区 Wiki。

标签： language-agnostic project-management internationalization yagni

【解决方案1】：

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

然而，这还不是全部。

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

不难。不可能。

考虑一下。

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

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

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

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

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

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

【讨论】：

您的示例提供了另一个案例研究。 I18n 并不像用另一种语言替换字符串那么简单，您必须将系统设计为与 i18n 很好地配合使用。在这种情况下，连接字符串使 i18n 几乎不可能，直到该代码被替换。语法在其他语言中是不一样的！
“不重构就不可能”是“不可能”的功能等价物。如果你必须重构或重写，你不是在做 I18N，你的重写是一个更广泛（并且定义不太明确）的活动。
@nikie：如果您“在设计时考虑到 I18N”，那么您的所有消息字符串都在属性（或配置）文件中，并且您的应用程序会获取这些外部字符串。那是 I18N，没有进一步的工作要做。你是完全国际化的。剩下的就是使用locale 来表示日期和数字。无论如何你都应该这样做。
@S. Lott：对我来说，“设计时考虑到 I18N”的意思是：编写代码时，只需在以后简单地 GREPing/替换字符串文字，就可以为 I18N 做所有事情。这意味着，没有字符串连接代码或类似代码。但是您仍然可以使用字符串文字。如果你这样做了，以后的 I18N 并不比一开始的 I18N 难。
@nikie：这就是重点。使用 I18N 进行设计比尝试修复一个不是考虑 I18N 设计的程序要便宜。简单地避免串联是一个开始。只需稍多一点的前期成本，所有字符串文字都可以放入属性文件中。不管怎样，从 I18N 开始显然比返工便宜。

【解决方案2】：

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

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

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

【讨论】：

时间负担更少，但如果有 4 个开发人员正在努力减少时间，那就是 4 个开发人员正在获得报酬......
虽然这是真的，但 Chris 也（合理地）假设您也有一个客户为这 4 位开发人员付钱给您。当然，稍后再做可能会更昂贵（特别是因为您可能需要认真重构您的应用程序），但风险较小。一旦你已经有了收入来源，你宁愿花两个人月进行国际化，还是宁愿将收入来源推迟一个人月，从一开始就获得它？
有道理但措辞不佳恕我直言（没有冒犯）。我相信将 i18n 添加到现有应用程序肯定比从头开始工作要花费更多，所以你的第一段是错误的。但是，您是正确的，延迟 i18n 可能仍然是正确的商业决策：也许您需要快速收入才能生存，或者您可能需要早期成功为 i18n 努力筹集资金（我认为就是你所说的“拥有一个庞大的开发团队”的意思——人数是一回事，但如果你打算做 i18n，你还需要银行里的钱来支付他们。

【解决方案3】：

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

例如

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

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

有many other issues like this：你需要更多的 UI 空间，因为有些语言需要比英语更多的字符来表达相同的概念，东亚地区需要更大的字体，你需要在用户界面中使用本地化的日期/时间，但也许英美与数据库通信时，需要用分号作为CSV文件的分隔符，字符串比较和排序分别是文化、电话号码和地址...

所以你认为一个项目开始今天，必须国际化，或者是否可以将该决定推迟到未来取决于成功（或不成功）软件享有和地理需求分布？

视情况而定。具体项目国际化的可能性有多大？快速获得第一个版本有多重要？

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

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

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

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

【讨论】：

当您意识到不同的文化在如何对字符串进行排序甚至两个字符串是否相等方面没有一致意见时，最大的惊喜可能会出现。有些文化将两个 Unicode 字符串视为相同（它们甚至可能有不同数量的字符）

【解决方案6】：

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

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

a) 用户界面和

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

当您想要启用其他输入方案时，您会遇到非常糟糕的情况。

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

【讨论】：

【解决方案7】：

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

【讨论】：

【解决方案8】：

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

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

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

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

【讨论】：

【解决方案9】：

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

【讨论】：

【解决方案10】：

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

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

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

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

【讨论】：