Question

Most people would agree that internationalizing an existing app is more expensive than developing an internationalized app from scratch.

Is that really true? Or when you write an internationalized app from scratch the cost of doing I18N is just being amortized over multiple small assignments and nobody feels on his shoulders the whole weight of the internationalization task?

You can even claim that a mature app has many and many LOC that where deleted during the project’s history, and that they don’t need to be I18Ned if internationalization is made as an after thought, but would have been I18N if the project was internationalized from the very beggining.

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.

I am not talking about the ability to manipulate unicode data. That you have for free in most mainstream languages, databases and libraries. I am talking specifically of supporting your own software’s user interface in multiple languages and locales.

Answer 1

“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.

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

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.