I agree that unicode is ugly and stupid. But despite all that it persists, because it is the least stupid of all encodings. It's not like the ASCII characters of: Form Feed (0C), Device Control 1 through 4 (11 through 14), group separator (1D), and most other non-printable ASCII characters are a reasonable use of byte-space, or are useful to attempt to render to the screen.
And that is before you get into hijinks that can be played with backspace and del characters if they are rendered naively. (Though I love backspace for progress bars in the terminal)
If you just go into simple mode, ë, em-dash, symbols and emoji would be fine.
You could refuse to render any file encoded in UTF8, UTF16 etc. but that would be silly because by now, most files you're going to encounter (especially as a developer) use one of these encodings.
Or you could refuse to render anything outside of the ASCII range but then you're just assuming that the English-speaking world is all there is and that people of other language communities don't also have needs (such as having their name displayed properly). That's a pretty myopic view of the world IMHO.
I never installed fonts for asian characters on my pc and it hasn't affected me whatsoever. My terminal (which is what I use to manage files) also doesn't support right to left text and it has __never__ been an issue.
Pretty sure you're interacting with lots of people on this website who aren't English native speakers.
> I never installed fonts for asian characters on my pc and it hasn't affected me whatsoever. My terminal (which is what I use to manage files) also doesn't support right to left text and it has __never__ been an issue.
That's not "turning off Unicode", that's just not installing fonts that deal with certain character ranges. Pretty sure whatever font you're using does support more than just bare ASCII, though.
The reasoning is that my primary computer use is in a single language. I very very rarely need to have my computer understand and present to me multiple different languages, and never languages that follow different rules. Anytime such a thing occurs:
a) it is not a language I understand, so not rendering it is fine & safe
b) someone is playing games with Unicode to try to trick me. Definitely not rendering is fine and rendering is actually dangerous
c) the most rare case: the other language is relevant. The only times this has happened (talking to my family and whatnot), it is local to a specific app and I only want that app to deal with the other languages.
The problem is that in the interest of satisfying every language group, my computers assume I care about all languages. I don't, I only speak/read 4 languages and everything else is no use being presented to me. If I'm an outlier, I'm an outlier for being fluent in more than a single language.
For most all users, having the system limited to presenting a single language would significantly reduce the attack surface.
But I still don't see this as a problem. Allowing arbitrary encodings, arbitrary mix in an single text stream of right-to-left and left-to-right rendering, homonyms and visually identical rendering of different byte sequences are all a problem, and in particular when any of these are being used across a web or OS interface, where recognizing the intent is quite important.
The problem is not Unicode rendering. The problem is improperly mingling information of a different nature. File extensions are not a good way to tell you if a file will be executed (Unix got that right from the start). Then executing a file involuntary shouldn’t lead to significant risks for your data and your system. That’s the actual problem which needs to be solved. Mangling text rendering is not the solution.
That'd be way too extreme but it would have been totally possible to have a filesystem configurable so that it'd enforce ASCII only filenames and ASCII only domain names.
FWIW I enforce ASCII only domain names on my system (I prevent resolving any domain name that has Unicode chars) and live is fine and well. And I'd have zero issue with ASCII-only filenames.
And localization/internationalization (l10n/i18n) can go where it should: inside resource files etc.
In some cases, you can get close enough by just cutting away random symbols. Think é -> e. Sure, you may lose some nuance, but it's close enough. I wonder how well this works for languages which don't use a latin-based script, and how approachable the conversion is for a "regular person".
Not always. For instance, "coco" means coconut, while "cocô" (notice the circumflex, which corresponds to a change on which syllabe has the stress) means fecal matter. That's not just "some nuance".
I love it when people are incensed on my behalf on things I actually don't care about.
No, the word does have a circumflex, not an acute accent, and it's also used by adults (mostly in the expression "fazer cocô", which means to defecate). But, of course, that might be something regional to where I live (a large metropolitan area on the southeast region of Brazil).