If you truly think you get "unicode handling" "for free", you may have a surprise coming your way when you try.
Unless you use a framework that has proven i18n ability beyond languages with the ANSI or very similar character sets, you will find several niggles and more major issues where the unicode handling isn't quite right, or simply unavailable. Even with relatively common languages (e.g. German) you can run into difficulty with shrinking or expanding letter counts and APIs that don't support unicode.
And then think of languages with different reading-ordering!
This is one of the reasons you should really plan it in from the beginning, and test the stuff to destruction on the set of languages you plan to support.
The concept of i18n and l10n is broader than merely translating strings to and fro some languages.
Example: Consider the input of date and time by users. If you haven't internationalization in mind when you design
a) the interface for the user and
b) the storage, retrieval and display mechanism
you will get a really bad time, when you want to enable other input schemes.
Agreed, in most cases i18n is not necessary in the first place. But, and that is my point, if you don't spend a thought on some areas, that must be touched for i18n, you will find yourself ending up rewriting large portions of the original code. And then, adding i18n is a lot more expensive than having spent some thought beforehand.
One thing that seems like it can be a big issue is the different character counts for a message in various languages. I do some work on iPhone apps and especially on a small screen if you design the UI for a message that has 10 characters and then you try to internationalize later and find you need 20 characters to display the same thing you now have to redo your UI to accommodate. Even with desktop apps this can still be a large PITA.
It depends on your project and how your team is organised.
I've been involved in the internationalization of a website, and it was one developer full-time for a year, probably about 6-8 months part-time for me to handle installation impacts when needed (reorganising files, etc), and other developers getting involved from time to time when their projects needed heavy refactoring. This was in an application that was at v3.
So that's definitely expensive. What you have to ask is how expensive is it to provide a localization system from the start, and how will that impact the project in the early stages. Your project at v1 may not be able to survive delays and setbacks caused by issues with a hastily-designed internationalization framework, while a stable v3 project with a wide customer base may have the capital to invest in doing that properly.
It also depends on whether you want to internationalize everything including log messages, or just the UI strings, and how many of those UI strings there are, and who you have available to do localization and the QA that goes with it, and even what languages you want to support - for example, does your system need to support unicode strings (which is a requirement for Asian languages).
And don;t forget that changing the database backend to support internationalized data can be costly as well. Just try to change that varchar field to nvarchar when you already have 20,000,000 records.
奇怪的字符串连接不属于 j2ee 文化，因为您知道有一天有人可能想要将其国际化。唯一的问题是从 html 模板中提取标签。
I think it depends on a language. Every j2ee(java web) app is i18n, because its very easy(even IDE can extract strings for you and you just name them).
In j2ee its cheaper to add it later, however the culture is to add them as soon as possible. I think its because j2ee uses a lot of open-source and almost all open-source libs are i18n. its great idea for them, but not for most j2ee app. most enterprise apps are just for one company that speak one language.
Plus if you have bad testers putting it too soon makes them give you bug reports about labels and translations(I only once saw translations done NOT by developers). After testers are done with it you have buggy app with excellent i18n support. However it might be fun for users to switch language and see if they can use it. However using your app its just boring work for them, so they wont even do that. The only users of i18n are the testers.
Weird string joining is not in j2ee culture since you know that one day someone might want to make it i18n. Only problem is extracting labels from html templates.
You're going to have a terrible time finding all of these kinds of situations. After all, some_function just returns a String. You don't know if it's a database key (never shown to a person) or a message which must be translated. And when it's translated, grammar rules may reveal that a 3-part string concatenation was a dumb idea.
You can't simply GREP every String-valued function as containing a possible I18N message that must be translated. You have to actually read the code, and possibly rewrite the function.
Clearly, when some_function has any complexity to it at all, you're stumped as to why one part of your application is still in Swedish while the rest was successfully I18N'd into other languages. (Not to pick on Swedes in particular, replace this with any language used for development different from final deployment.)
Worse, of course, if you're working in C or C++, you might have some of this split between pre-processor macros and proper C-language syntax.
And in a dynamic language -- where code can be built on the fly -- you'll be paralyzed by a design in which you can't positively identify all the code. While dynamically generating code is a bad idea, it also makes your retroactive I18N job impossible.
I'm going to have to disagree that it costs more to add it to an existing application than from scratch with a new one.
A lot of the time i18n is not required until the application gets 'big'. When you do get big, you will likely have a bigger development team to devote to i18n so it will be less of a burden.
You may not actually need it. A lot of small teams put great effort to support internationalization when you have no customers who require it.
Once you have internationalized, it makes incremental changes more time consuming. It doesn't take a lot of extra time but every time you need to add a string to the product, you need to add it to the bundle first and then add a reference. No it is not a lot of work but it is effort and does take a bit of time.
I prefer to 'cross that bridge when we come to it' and internationalize only when you have a paying customer looking for it.
Yes, internationalizing an existing app is definitely more expensive than developing the app as internationalized from day one. And it's almost never trivial.
For instance
Message = "Do you want to load the " & fileType() & " file?"
cannot be internationalised without some code alterations because many languages have grammatical rules like gender agreement. You often need a different message string for loading every possible file type, unlike in English when it's possible to bolt together substrings.
There are many other issues like this: you need more UI space because some languages need more characters than English to express the same concept, you need bigger fonts for East Asia, you need to use localised date/times in the user interface but perhaps English US when communicating with databases, you need to use semicolon as a delimeter for CSV files, string comparisons and sorting are cultural, phone numbers & addresses...
So do you think a project starting today, must be internationalized, or can that decision be deferred to the future based on the success (or not) the software enjoys and the geographic distribution of the demand?
It depends. How likely is the specific project to be internationalised? How important it is to get a first version fast?
发布评论
评论（10）
如果您真的认为您可以“免费”获得“unicode 处理”，那么当您尝试时，您可能会感到惊讶。
除非您使用的框架已证明具有超越 ANSI 或非常相似字符集的语言的 i18n 能力，否则您会发现一些小问题和更主要的问题，其中 unicode 处理不太正确，或者根本不可用。即使使用相对常见的语言（例如德语），您也可能会在缩小或扩大字母数以及不支持 unicode 的 API 方面遇到困难。
然后想想具有不同阅读顺序的语言！
这是您应该从一开始就真正计划它的原因之一，并在您计划支持的语言集上测试这些内容以进行破坏。
If you truly think you get "unicode handling" "for free", you may have a surprise coming your way when you try.
Unless you use a framework that has proven i18n ability beyond languages with the ANSI or very similar character sets, you will find several niggles and more major issues where the unicode handling isn't quite right, or simply unavailable. Even with relatively common languages (e.g. German) you can run into difficulty with shrinking or expanding letter counts and APIs that don't support unicode.
And then think of languages with different reading-ordering!
This is one of the reasons you should really plan it in from the beginning, and test the stuff to destruction on the set of languages you plan to support.
i18n 和 l10n 的概念比仅仅在某些语言之间翻译字符串更广泛。
示例：考虑用户输入的日期和时间。 时没有考虑到国际化，那么
如果您在设计a）用户界面和
b）存储、检索和显示机制
当您想要启用其他输入方案时，您将会遇到非常糟糕的情况。
同意，在大多数情况下 i18n 并不是必需的。但是，这就是我的观点，如果您不考虑 i18n 必须触及的某些领域，您会发现自己最终重写了大部分原始代码。然后，添加 i18n 比事先花一些心思要昂贵得多。
The concept of i18n and l10n is broader than merely translating strings to and fro some languages.
Example: Consider the input of date and time by users. If you haven't internationalization in mind when you design
a) the interface for the user and
b) the storage, retrieval and display mechanism
you will get a really bad time, when you want to enable other input schemes.
Agreed, in most cases i18n is not necessary in the first place. But, and that is my point, if you don't spend a thought on some areas, that must be touched for i18n, you will find yourself ending up rewriting large portions of the original code. And then, adding i18n is a lot more expensive than having spent some thought beforehand.
有一件事看起来可能是一个大问题，那就是不同语言的消息的字符数不同。我在 iPhone 应用程序上做了一些工作，特别是在小屏幕上，如果您为包含 10 个字符的消息设计 UI，然后您稍后尝试国际化，发现需要 20 个字符来显示相同的内容，您现在必须重做 UI来容纳。即使使用桌面应用程序，这仍然是一个很大的 PITA。
One thing that seems like it can be a big issue is the different character counts for a message in various languages. I do some work on iPhone apps and especially on a small screen if you design the UI for a message that has 10 characters and then you try to internationalize later and find you need 20 characters to display the same thing you now have to redo your UI to accommodate. Even with desktop apps this can still be a large PITA.
这取决于您的项目以及您的团队的组织方式。
我参与过一个网站的国际化，由一名开发人员全职工作了一年，大概有 6-8 个月的兼职时间让我在需要时处理安装影响（重新组织文件等），以及其他工作当项目需要大量重构时，开发人员会不时参与其中。这是在 v3 版本的应用程序中。
所以这肯定很贵。您要问的是，从一开始就提供本地化系统的成本是多少，以及这对早期阶段的项目有何影响。您的 v1 项目可能无法承受因仓促设计的国际化框架问题而导致的延迟和挫折，而拥有广泛客户群的稳定 v3 项目可能有资本投资来正确地做到这一点。
它还取决于您是否想要国际化所有内容，包括日志消息，或者只是 UI 字符串，以及这些 UI 字符串有多少，以及谁可以进行本地化和随之而来的 QA，甚至是哪些语言您想要支持 - 例如，您的系统是否需要支持 unicode 字符串（这是亚洲语言的要求）。
It depends on your project and how your team is organised.
I've been involved in the internationalization of a website, and it was one developer full-time for a year, probably about 6-8 months part-time for me to handle installation impacts when needed (reorganising files, etc), and other developers getting involved from time to time when their projects needed heavy refactoring. This was in an application that was at v3.
So that's definitely expensive. What you have to ask is how expensive is it to provide a localization system from the start, and how will that impact the project in the early stages. Your project at v1 may not be able to survive delays and setbacks caused by issues with a hastily-designed internationalization framework, while a stable v3 project with a wide customer base may have the capital to invest in doing that properly.
It also depends on whether you want to internationalize everything including log messages, or just the UI strings, and how many of those UI strings there are, and who you have available to do localization and the QA that goes with it, and even what languages you want to support - for example, does your system need to support unicode strings (which is a requirement for Asian languages).
并且不要忘记，更改数据库后端以支持国际化数据的成本也可能很高。当您已经拥有 20,000,000 条记录时，只需尝试将该 varchar 字段更改为 nvarchar 即可。
And don;t forget that changing the database backend to support internationalized data can be costly as well. Just try to change that varchar field to nvarchar when you already have 20,000,000 records.
我认为这取决于语言。每个 j2ee(java web) 应用程序都是 i18n，因为它非常简单（甚至 IDE 都可以为您提取字符串，您只需命名它们）。
在 j2ee 中，稍后添加会更便宜，但文化是尽快添加它们。我认为这是因为j2ee使用了大量开源库并且几乎所有开源库都是i18n的。对于他们来说这是个好主意，但对于大多数 j2ee 应用程序来说却不是。 大多数企业应用程序仅适用于使用一种语言的一家公司。
另外，如果你有糟糕的测试人员，太早的话会让他们给你有关标签和翻译的错误报告（我只见过一次不是由开发人员完成的翻译）。测试人员完成后，您会得到一个有缺陷的应用程序，并且具有出色的 i18n 支持。然而，对于用户来说，切换语言并看看他们是否可以使用它可能会很有趣。然而，使用你的应用程序对他们来说只是无聊的工作，所以他们甚至不会这样做。 i18n 的唯一用户是测试人员。
奇怪的字符串连接不属于 j2ee 文化，因为您知道有一天有人可能想要将其国际化。唯一的问题是从 html 模板中提取标签。
I think it depends on a language. Every j2ee(java web) app is i18n, because its very easy(even IDE can extract strings for you and you just name them).
In j2ee its cheaper to add it later, however the culture is to add them as soon as possible. I think its because j2ee uses a lot of open-source and almost all open-source libs are i18n. its great idea for them, but not for most j2ee app. most enterprise apps are just for one company that speak one language.
Plus if you have bad testers putting it too soon makes them give you bug reports about labels and translations(I only once saw translations done NOT by developers). After testers are done with it you have buggy app with excellent i18n support. However it might be fun for users to switch language and see if they can use it. However using your app its just boring work for them, so they wont even do that. The only users of i18n are the testers.
Weird string joining is not in j2ee culture since you know that one day someone might want to make it i18n. Only problem is extracting labels from html templates.
我不能说什么是昂贵的，但是，我可以告诉你，一个干净的 API 可以让你以非常低的成本国际化你的应用程序。
I cant say what is expensive but, i can tell you that a clean API lets you internationalise your Aplication at very low cost.
“当你从头开始编写一个国际化应用程序时，国际化的成本是......摊销的”
然而，这并不是故事的全部。
在某些情况下，追溯发送给用户的每条消息是不可能的。
不难。不可能的。
考虑一下这一点。
遇到所有这些情况你将会经历一段糟糕的时光。毕竟，
some_function只是返回一个字符串。您不知道它是数据库密钥（从未向人显示）还是必须翻译的消息。当它被翻译时，语法规则可能会表明三部分字符串连接是一个愚蠢的想法。您不能简单地将每个字符串值函数视为包含必须翻译的可能的 I18N 消息。您必须实际阅读代码，并可能重写该函数。
显然，当
some_function具有任何复杂性时，您会很困惑为什么应用程序的一部分仍然是瑞典语，而其余部分已成功国际化为其他语言。 （特别不是针对瑞典人，请将其替换为与最终部署不同的用于开发的任何语言。）当然，更糟糕的是，如果您使用 C 或 C++ 工作，则可能会在预处理器宏之间存在一些这种划分以及正确的 C 语言语法。
在动态语言中（可以动态构建代码），您将因无法明确识别所有代码的设计而陷入瘫痪。虽然动态生成代码是一个坏主意，但它也会使您的追溯 I18N 工作变得不可能。
"when you write an internationalized app from scratch the cost of doing I18N is ... amortized"
However, that's not the whole story.
Retroactively tracking down every message to the users is -- in some cases -- impossible.
Not hard. Impossible.
Consider this.
You're going to have a terrible time finding all of these kinds of situations. After all,
some_functionjust returns a String. You don't know if it's a database key (never shown to a person) or a message which must be translated. And when it's translated, grammar rules may reveal that a 3-part string concatenation was a dumb idea.You can't simply GREP every String-valued function as containing a possible I18N message that must be translated. You have to actually read the code, and possibly rewrite the function.
Clearly, when
some_functionhas any complexity to it at all, you're stumped as to why one part of your application is still in Swedish while the rest was successfully I18N'd into other languages. (Not to pick on Swedes in particular, replace this with any language used for development different from final deployment.)Worse, of course, if you're working in C or C++, you might have some of this split between pre-processor macros and proper C-language syntax.
And in a dynamic language -- where code can be built on the fly -- you'll be paralyzed by a design in which you can't positively identify all the code. While dynamically generating code is a bad idea, it also makes your retroactive I18N job impossible.
我不得不同意将其添加到现有应用程序比从头开始添加新应用程序的成本更高。
我更喜欢“当我们到达时跨过那座桥”，只有当你有付费客户寻找它时才进行国际化。
I'm going to have to disagree that it costs more to add it to an existing application than from scratch with a new one.
I prefer to 'cross that bridge when we come to it' and internationalize only when you have a paying customer looking for it.
是的，国际化现有应用程序肯定比从一开始就开发国际化应用程序更昂贵。这几乎从来都不是微不足道的。
例如，
如果不进行一些代码更改就无法国际化，因为许多语言都有诸如性别协议之类的语法规则。您通常需要不同的消息字符串来加载每种可能的文件类型，这与英语不同，可以将子字符串连接在一起。
还有许多其他类似的问题：你需要更多的 UI 空间，因为某些语言需要比英语更多的字符来表达相同的概念，东亚你需要更大的字体，你需要在用户界面中使用本地化的日期/时间，但也许美国英语在与数据库通信时，你需要使用分号作为 CSV 文件的分隔符，字符串比较和排序是文化、电话号码和文本。地址...
这取决于。具体项目国际化的可能性有多大？快速获得第一个版本有多重要？
Yes, internationalizing an existing app is definitely more expensive than developing the app as internationalized from day one. And it's almost never trivial.
For instance
cannot be internationalised without some code alterations because many languages have grammatical rules like gender agreement. You often need a different message string for loading every possible file type, unlike in English when it's possible to bolt together substrings.
There are many other issues like this: you need more UI space because some languages need more characters than English to express the same concept, you need bigger fonts for East Asia, you need to use localised date/times in the user interface but perhaps English US when communicating with databases, you need to use semicolon as a delimeter for CSV files, string comparisons and sorting are cultural, phone numbers & addresses...
It depends. How likely is the specific project to be internationalised? How important it is to get a first version fast?