Closed. This question is
opinion-based。它当前不接受答案。
想要改善这个问题吗？更新问题，以便
editing this post用事实和引用来回答。
1年前关闭。
Improve this question
大多数人会同意，对现有应用程序进行国际化的成本要比从头开始开发国际化应用程序的成本高。
真的是这样吗？还是当您从头开始编写国际化应用程序时，I18N的成本只是在多个小任务上摊销而没有人感觉到国际化任务的全部重担？
您甚至可以声称成熟的应用程序具有在项目历史记录中删除的很多LOC，并且如果事后考虑将其国际化，则无需将其设为I18Ned；如果将项目国际化，则将其称为I18N。从最开始的时候开始。
因此，您认为从今天开始的项目，
是否必须进行国际化，或者可以根据软件的成功与否以及需求的地理分布，将该决定推迟到将来。
我不是在谈论处理unicode数据的能力。您可以免费使用大多数主流语言，数据库和库。我的意思是专门支持多种语言和区域设置的自己的软件的用户界面。
“当您从头开始编写国际化应用程序时，将分摊I18N的成本”
但是，这还不是全部。
在某些情况下，追溯追溯到用户的每条消息是不可能的。
不难。不可能的。
考虑一下。
theMessage = "Some initial part" + some_function() + "some following part";
您将很难找到所有这些情况。毕竟，
some_function仅返回字符串。您不知道它是数据库 key (从未显示给他人)还是必须翻译的消息。并且在翻译时，语法规则可能会显示一个由三部分组成的字符串串联是一个愚蠢的主意。
您不能简单地将每个String值的函数都包含在GREP中，因为它包含可能必须转换的I18N消息。您必须实际阅读代码，并可能重写函数。
显然，当
some_function根本没有任何复杂性时，您会感到困惑，为什么您的应用程序的一部分仍然使用瑞典语，而其余部分却被成功地翻译成其他语言。 (不要特别选择瑞典人，请使用与最终部署不同的任何用于开发的语言来代替它。)
当然，更糟糕的是，如果您使用的是C或C++，则可能在预处理器宏和正确的C语言语法之间进行了部分拆分。
而在动态语言中-可以动态构建代码-您将陷入无法肯定地识别所有代码的设计的困境。尽管动态生成代码不是一个好主意，但它也使您无法进行I18N追溯工作。