Falsehoods Programmers Believe About Plain Text (2021)(jeremyhussell.blogspot.com)
jeremyhussell.blogspot.com
Falsehoods Programmers Believe About Plain Text (2021)
https://jeremyhussell.blogspot.com/2017/11/falsehoods-programmers-believe-about.html
4 comments
Teams manages to be worse. You can copy text in planner and paste it in the same description box and it will magically go from sans-serif to serif.
I don't know how you can fuck up like this.
I don't know how you can fuck up like this.
I've seen this list before. It's useful to think about, sometimes. But falsehoods lists really need counterexamples to be useful in practice.
There’s a link at the top that toggles examples and discussion.
Honestly, I'm going to go against the grain here and say that 99% of the time, this is needless pedantry. Yes, these assumptions are technically wrong, but most of the time, let's be real, they're right, or else people wouldn't be able to get away with making them.
Characters are integers, that is a fact. Most of the time, they're a byte, and to be honest, English/ASCII is the most important text setup for computers and it's fine to only support that. For the niche foreign edge cases, Windows supports UCS-2.
Characters are integers, that is a fact. Most of the time, they're a byte, and to be honest, English/ASCII is the most important text setup for computers and it's fine to only support that. For the niche foreign edge cases, Windows supports UCS-2.
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.
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.
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.
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.
“Text copied from MS word and pasted on a text field will have some resemblance to the original text”