Language agnostic 以后国际化真的更贵吗？

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

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

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

因此，您认为从今天开始的项目必须国际化，还是可以根据软件的成功（或失败）和需求的地理分布推迟到将来

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

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

然而，这并不是全部

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

不难。不可能

想想这个

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

你将很难找到所有这些情况。毕竟，

某个函数只返回一个字符串。您不知道它是数据库密钥（从未向任何人显示）还是必须翻译的消息。当它被翻译时，语法规则可能会揭示，由三部分组成的字符串串联是一个愚蠢的想法

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

显然，当
某个函数有任何复杂性时，您会被难倒，为什么应用程序的一部分仍然是瑞典语，而其余部分成功地翻译成了其他语言。（不要特别挑剔瑞典人，用任何与最终部署不同的开发语言来代替它。）

<> P>更糟的是，如果你在C或C++中工作，你可能会在预处理器宏和适当的C语言语法之间有一些分裂。
在一种动态语言中——代码可以动态生成——你会被一种无法准确识别所有代码的设计所麻痹。虽然动态生成代码是一个坏主意，但它也使您的追溯I18N工作变得不可能。
我不同意将其添加到现有应用程序比从头开始使用新应用程序花费更多


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

我更喜欢“当我们到达它时跨越这座桥”，只有当你有付费客户在寻找它时才国际化。
我不能说什么是昂贵的，但我可以告诉你，一个干净的API可以让你以非常低的成本国际化你的应用程序。
如果你真的认为你可以免费获得“unicode处理”，当你尝试时，你可能会有一个惊喜

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

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

这就是你应该从一开始就计划好的原因之一，并在你计划支持的一组语言上测试这些东西直到销毁。
i18n和l10n的概念比仅仅在某些语言之间来回翻译字符串更广泛

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

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

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

同意，在大多数情况下，i18n首先是不必要的。但是，这就是我的观点，如果你不花一点时间思考i18n必须涉及的一些领域，你会发现自己最终会重写大部分原始代码。然后，添加i18n比事先花点时间考虑要昂贵得多。
有一件事似乎会成为一个大问题，那就是不同语言中消息的字符数不同。我在iPhone应用程序上做了一些工作，特别是在小屏幕上，如果你为一条包含10个字符的消息设计UI，然后你尝试稍后进行国际化，发现需要20个字符才能显示你现在必须重做UI才能适应的内容。即使使用桌面应用程序，这仍然是一个很大的难题。
是的，将现有应用程序国际化肯定比从第一天开始将应用程序国际化要贵。一
Message = "Do you want to load the " & fileType() & " file?"