> It's easy to say "let's go back to the time when things were simple"; it's a lot harder to say "folks in (e.g.) Israel shouldn't be able to type in their native language".
Is writing a text editor literally so hard that we can't do it twice (or three, or five times)?
There are literally trillions of lines of code in existence now. Instead of making a five hundred thousand line text editor because are terrified of writing one again, maybe we make five ten thousand line editors?
Of course, I'm exaggerating, but do you get my point? There are worse things than duplicated code. Narrowing the requirements for latin and cyrillic left-to-right languages so their code can be made radically simpler seems well worth it! The specialization necessary to make a text editor do Hebrew well, or Chinese or Arabic well is probably way different, and frankly, better done by experts in those languages. From their perspective, to completely flip it around, why should their editors be encumbered by the need to support English? Instead we end up with the proverbial "Jack of all trades, master of none". And we end up with radically complicated, hard to test, terrified-of-breaking-a-language-I-don't understand code that serves no one well.
Editors don't have have to completely diverge in features and feel just because they might have different code bases. Surely we can try to make copy&paste and select all and the common things operate in a fairly standard way across a few different programs.
People who work in multiple languages probably wouldn't be too happy with this. (Particularly not with dropping English since it's the most common second language.)
This also isn't going to work economically for companies selling consumer apps because they aren't going to want to limit their market to a one country, particularly if it's a small one. There's more money in targeting the world, so programmers just have to deal. (The support matrix is often complicated already with multiple platforms to support.)
I think it's fine in many cases to target limited audiences. Companies often have internal apps that aren't internationalized. But the popular apps that we all use have to be very complicated because they actually do try to be universal.
Conceivably we'd be better off with a compound-document standard, like the 90s attempts OLE and OpenDoc but somehow nicer. Then multilanguage documents, with specialized editors, would fall out as one use for compound documents.
This is what was done with codepages before the advent of the internet, basically. The problem that arose was transferring information between systems - even without the internet it was needed at areas that were near borders, etc.
Is writing a text editor literally so hard that we can't do it twice (or three, or five times)?
There are literally trillions of lines of code in existence now. Instead of making a five hundred thousand line text editor because are terrified of writing one again, maybe we make five ten thousand line editors?
Of course, I'm exaggerating, but do you get my point? There are worse things than duplicated code. Narrowing the requirements for latin and cyrillic left-to-right languages so their code can be made radically simpler seems well worth it! The specialization necessary to make a text editor do Hebrew well, or Chinese or Arabic well is probably way different, and frankly, better done by experts in those languages. From their perspective, to completely flip it around, why should their editors be encumbered by the need to support English? Instead we end up with the proverbial "Jack of all trades, master of none". And we end up with radically complicated, hard to test, terrified-of-breaking-a-language-I-don't understand code that serves no one well.
Editors don't have have to completely diverge in features and feel just because they might have different code bases. Surely we can try to make copy&paste and select all and the common things operate in a fairly standard way across a few different programs.