3 ms·

I'm not so sanguine. I see it as you can be mostly wrong, mostly correct, or very close to correct, for the software that you write and the customers it serves

I'm not so sanguine. I see it as you can be mostly wrong, mostly correct, or very close to correct, for the software that you write and the customers it serves at a given point in time . Any of those choices are fine, so long as you know what you are getting into. So for example if you are writing a CLI utility for the European market, you could probably get away with doing very little, it would be an ugly experience for, say, German users, but it would be quick. You could go to the next level, eg, supporting umlauts and ß, and that would have a big payoff. You could probably stop there. But if you were writing a utility to do OCR on ancient texts, you'd have to go full-bore and support everything..and you'd still be wrong on occasion. It's just a question of economic tradeoffs being explicitly judged and thought about, and not assumed away.

cwstarblazer 3y ago
Yeah, I do take your point, and I never denied that all of these are going to be valid consideration for some program for some customer somewhere, my main point was that in most cases, it doesn't matter. Like you said, one could probably stop there in most cases. Obviously, the needs of a program doing OCR for ancient languages is different than something spitting out and reading in text from a console or even a Win32 text entry field.
- kjellsbells 3y ago
  Yup. One thing that remains unclear to me (commercially) is: is it better to not internationalize at all if you cant do it perfectly? I honestly don't know the answer. A trivial example I came across the other day was a Spanish hotel website, which had multiple versions for EN/ES/PT etc, but when you came to book, presented some page elements in Spanish and some in English. Would have been better to stixk with one language than do it badly. Which brings me to the point: this is really about money. Internationalization done properly costs serious coin.

cwstarblazer 3y ago

Yeah, I do take your point, and I never denied that all of these are going to be valid consideration for some program for some customer somewhere, my main point was that in most cases, it doesn't matter. Like you said, one could probably stop there in most cases. Obviously, the needs of a program doing OCR for ancient languages is different than something spitting out and reading in text from a console or even a Win32 text entry field.

kjellsbells 3y ago
Yup. One thing that remains unclear to me (commercially) is: is it better to not internationalize at all if you cant do it perfectly? I honestly don't know the answer. A trivial example I came across the other day was a Spanish hotel website, which had multiple versions for EN/ES/PT etc, but when you came to book, presented some page elements in Spanish and some in English. Would have been better to stixk with one language than do it badly. Which brings me to the point: this is really about money. Internationalization done properly costs serious coin.