4 ms·

At this point the user will discover that easy to type unambiguously encoded filenames have value, and may opt to save the Á's for when they actually are writin

by Wicher 4y ago

At this point the user will discover that easy to type unambiguously encoded filenames have value, and may opt to save the Á's for when they actually are writing a letter to grandma. "But that's subjecting the user to limitations of the system!" you might object, and while you'd be right we should also ponder whether a filesystem is a word processor or a system for locating data using filenames as identifiers, and consequently, what sound handling of identifiers is. And let's be realistic. Most users will choose the file to open from a file picker dialog. fopen() is not their interface, their interface is a file picker. The intersection of people for whom fopen() is their interface (no file pickers) but for whom learning lessons on the value of using unambiguous identifiers is somehow out of reach, would be exceedingly small.

hibbelig 4y ago
> At this point the user will discover that easy to type unambiguously encoded filenames have value, and may opt to save the Á's for when they actually are writing a letter to grandma. The unambiguously encoded filenames wouldn't be in the natural language of the user, so you're asking the user to learn another language. Users shouldn't have to learn another language to use the computer.
- Wicher 4y ago
  I'm not 100% sure on this, but in many/most/all scripts, wouldn't there be a subset of characters in unicode for which you don't need to worry about unicode ambiguities with respect to combining characters? For prose of course it wouldn't be acceptable if you can't use your full language, but this is a filesystem, and we're talking identifiers, not prose. We accept that for a wide range of everyday things — I don't think many people are getting worked up about web forms not accepting their phone numbers when entered in Latin numerals. Using bytestring labels sans normalization is just the rational choice, and actually quite accommodating. People _can_ use their natural language. If you can encode your prose in bytes, then there you go, that'll be your filename ;-) and if you can't remember what diacritic-combining strategy you used when you created the file, and can't manage to fopen() it anymore by typing out the filename, use a file picker or search. And then, perhaps, go "that was a hassle, I'll avoid those fu͝n͜n͏y͝ sq̧u͜igg̶l̢įȩş for my next filename, computer are stupid" - not the end of the world, not the worst outcome.
  - hibbelig 4y ago
    I'm not 100% certain, either. Hasn't someone else here written that all of the Korean characters can be expressed in two ways? Then there is Vietnamese which has a lot of accents and other diacritics. Not sure how much you can do without them. Perhaps a language like Chinese doesn't have so many ambiguities, as in there is only one way to encode a given character in Unicode?

by Wicher 4y ago

hibbelig 4y ago

> At this point the user will discover that easy to type unambiguously encoded filenames have value, and may opt to save the Á's for when they actually are writing a letter to grandma. The unambiguously encoded filenames wouldn't be in the natural language of the user, so you're asking the user to learn another language. Users shouldn't have to learn another language to use the computer.

Wicher 4y ago
I'm not 100% sure on this, but in many/most/all scripts, wouldn't there be a subset of characters in unicode for which you don't need to worry about unicode ambiguities with respect to combining characters? For prose of course it wouldn't be acceptable if you can't use your full language, but this is a filesystem, and we're talking identifiers, not prose. We accept that for a wide range of everyday things — I don't think many people are getting worked up about web forms not accepting their phone numbers when entered in Latin numerals. Using bytestring labels sans normalization is just the rational choice, and actually quite accommodating. People _can_ use their natural language. If you can encode your prose in bytes, then there you go, that'll be your filename ;-) and if you can't remember what diacritic-combining strategy you used when you created the file, and can't manage to fopen() it anymore by typing out the filename, use a file picker or search. And then, perhaps, go "that was a hassle, I'll avoid those fu͝n͜n͏y͝ sq̧u͜igg̶l̢įȩş for my next filename, computer are stupid" - not the end of the world, not the worst outcome.
- hibbelig 4y ago
  I'm not 100% certain, either. Hasn't someone else here written that all of the Korean characters can be expressed in two ways? Then there is Vietnamese which has a lot of accents and other diacritics. Not sure how much you can do without them. Perhaps a language like Chinese doesn't have so many ambiguities, as in there is only one way to encode a given character in Unicode?