Vincent Gable’s Blog

With every programming language/development environment I know of, you have to do extra work to make a string localizable. For example,
errorMessage = NSLocalizedString(@"This is hard!",@"");
not simply,
errorMessage = @"This is hard!";

And it’s not just extra work, it’s a ridiculous amount of work. E.g. to create an Objective-C string, you just put an @ in front of a standard C string. But to create a localized string, you have to surround your string in ()‘s, and prefix it with a seventeen character mixed-case function-name, and finally add an empty “note” for the translator. (Rarely, you may want to add a note for the translator, and it’s good that you can, but you should not be forced to write something when it is not necessary.)

There isn’t really an excuse for this; it’s just how languages have lazily evolved.

Non-localizable (“hardcoded”) strings are a huge issue, even though they are trivially simple for programmers to fix. The problem is that translators do not work with source code, they work with resource files. So when they find a “hardwired” string that must be changed in code, they tell a programmer to fix it. And that communication is slow and costly. Especially when you consider that good localizers are probably native to the place they are localizing for — meaning that having a real-time conversation involves at least one party staying up past 3AM.

I dream of a day where "this would be localized by default"; "and"("syntactic sugar for adding optional translator notes would be there too"); and creating C"literal C-strings" would be easy.

“Unicode support libraries” are doomed to institutionalized-failure, because they will never make it easier to do the right thing. It must be so easy to create a localizable program that you wouldn’t dream of doing anything else.