国际化后来真的更贵吗？

Question

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

这是真的吗？或者当你从零开始编写一个国际化的应用程序时,做I18N的成本只是在多个小任务上分摊,并且没有人感觉到国际化任务的全部重要性？

你甚至可以声称一个成熟的应用程序有很多很多LOC在项目历史中被删除了,并且如果国际化是作为一个思想进行的话,它们不需要是I18Ned,但如果项目是国际化的话,它将是I18N从非常开始.

那么你认为从今天开始的项目必须国际化,或者根据软件的成功(或不成功)和需求的地理分布,将决定推迟到未来.

我不是在谈论操纵unicode数据的能力.你在大多数主流语言,数据库和库中都是免费的.我所说的是专门用多种语言和语言环境支持您自己软件的用户界面.

Answer 1

"当你从头开始编写一个国际化的应用程序时,做I18N的成本是......摊销的"

然而,这不是整个故事.

在某些情况下,追溯性地向用户追踪每条消息是不可能的.

不难.不可能.

考虑一下.

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

找到所有这些情况你会很糟糕.毕竟,some_function只返回一个String.您不知道它是否是数据库密钥(从未向某人显示)或必须翻译的消息.当它被翻译时,语法规则可能会揭示出一个由3部分组成的字符串连接是一个愚蠢的想法.

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

显然,当它some_function有任何复杂性时,你会感到难过为什么你的应用程序的一部分仍然是瑞典语,而其余的部分成功地使用其他语言.(特别是不要选择瑞典语,将其替换为与最终部署不同的任何用于开发的语言.)

更糟糕的是,当然,如果您使用的是C或C++,您可能会在预处理器宏和正确的C语言语法之间进行一些划分.

并且在动态语言中 - 代码可以在运行中构建 - 您将因为无法正确识别所有代码的设计而陷入瘫痪.虽然动态生成代码是一个坏主意,但它也使你的追溯I18N工作变得不可能.

Answer 2

我不得不不同意将它添加到现有应用程序中的成本要高于从头开始添加新应用程序的成本.

• 在应用程序变得"大"之前,很多时候都不需要i18​​n.当你变大的时候,你可能会有一个更大的开发团队来投入i18n,这样就不会有负担.
• 你可能实际上并不需要它.当没有客户需要时,很多小团队都会付出巨大的努力来支持国际化.
• 一旦进行国际化,就会使增量更改更耗时.它不需要花费很多额外的时间,但每次需要向产品添加字符串时,您需要先将其添加到包中,然后添加引用.不,它不是很多工作,但它是努力,并确实需要一点时间.

我更愿意"当我们来到这座桥时跨越那座桥梁",并且只有当你有一位付费顾客寻找它时才会国际化.