后来的国际化真的更贵吗？

Question

大多数人会同意，将一个现有的应用程序国际化比从头开发一个国际化的应用程序要昂贵得多。

这真的是真的吗？或者，当你从头开始编写一个国际化的应用程序时，做I18N的成本只是通过多个小任务来摊销，而没有人觉得国际化任务的全部负担在他身上？

你甚至可以说，一个成熟的应用程序有许多在项目历史上删除的LOC，如果国际化是事后考虑的话，它们不需要是I18Ned，但是如果该项目是从穷困潦倒的国际化过程中国际化的话，它们就会成为I18N。

那么，您认为从今天开始的项目，必须国际化，还是可以根据软件的成功(或不满意)和需求的地理分布，将这一决定推迟到未来。

我不是在说操纵unicode数据的能力。在大多数主流语言、数据库和库中是免费的。我特别说的是用多种语言和地区支持您自己的软件的用户界面。

Answer 1

“当您从头开始编写国际化应用程序时，执行I18N的成本是.摊销的”

然而，这并不是全部。

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

不是很难。不可能。

考虑一下这个。

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

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

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

显然，当some_function对其有任何复杂性时，您会感到困惑，为什么您的应用程序的一部分仍然是瑞典语，而其余部分则成功地被i18n转换成其他语言。(不要特别挑剔瑞典人，代之以与最终部署不同的开发语言。)

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

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

Answer 2

我将不得不不同意将其添加到现有应用程序中所花费的成本，而不是从零开始添加一个新应用程序。

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

我更喜欢‘过桥，当我们来到它’和国际化，只有当你有一个付费客户寻找它。

Answer 3

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

例如

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

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

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

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

，这要看了。具体项目国际化的可能性有多大？快速获得第一个版本有多重要？