I mean, cases in non-latin alphabets are cases as long as they function like cases, equivalences between alphabets are not cases, they’re equivalences between alphabets and a different issue altogether. At least that’d be my starting point for implementation.
But you’re misrepresenting my argument. I don’t give a crap if it’s simple and obvious to implement and it’s not my claim that it is. If it’s simple and obvious to the user it’s still the right call, even if the implementation is complicated and has to deal with edge cases.
My last caveat there would be that nobody claimed that a one-size-fits-all is necessary. Ultimately you’re not deciding the case sensitiveness of databases, just of one database, and that’s the filesystem’s naming rules. The rules are arbitrary and conventional. Short of raw “any character code will always be different from any other character code regardless of how visually similar or grammatically interchangeable the user-facing glyphs may be” any other solution is just as arbitrary as each other. You’re always making a decision about it.
My contention is the decision shouldn’t be based on what is comfortable or more straightforward to implement, debug or use for the OS developers, it should be what is more usable by the lowest common denominator GUI-only users. And that’s case insensitive (but otherwise long and flexible) filenames.
Hardly, I’m directly addressing your statement that case insensitive is intuitive to users, grandmas or otherwise - I give examples where it’s not initiative or obvious which filenames match. I didn’t mention ease of implementation at all.
The principle of least surprise is an important UX consideration, and your idea of effectively introducing collation and localising which files conflict is just trading one problem for another set of problems and suprises (e.g. copying directories between drives with different settings).
No, it’s not. You’re substituting a base use case for an edge case and pretending they are on the same order when it comes to UX. They are not. File localization and mixing and matching alphabets in filenames is NOT the same as case sensitivity and using cases (or spaces, if we want to roll this conversation back a couple decades and talk about an actual implementation mess) in filesystems. Security and stability care about edge cases, it’s weird that you try to flex by name dropping “principle of least surprise” and then pretend that a problem impacting every single user who types a filename is the same impact on that than a user mixing and matching alphabets on multiple cases. ESPECIALLY when your example requires making the conscious decision that equivalent characters across alphabets is equivalent to case sensitivity, which is not a given at all.
Oh, and it’s not my idea. Default Windows and Mac FSs are case insensitive, legacy FAT systems are case insensitive. If the issue is standardization across systems, case sensistivity is the odd one out. If you’re having issues mixing and matching drives in older supported case-insensitive FSs the blanket fix for that is not having a case sensitive system elsewhere for no particularly good reason. I mean, speaking of minimizing surprise…
I mean, cases in non-latin alphabets are cases as long as they function like cases, equivalences between alphabets are not cases, they’re equivalences between alphabets and a different issue altogether. At least that’d be my starting point for implementation.
But you’re misrepresenting my argument. I don’t give a crap if it’s simple and obvious to implement and it’s not my claim that it is. If it’s simple and obvious to the user it’s still the right call, even if the implementation is complicated and has to deal with edge cases.
My last caveat there would be that nobody claimed that a one-size-fits-all is necessary. Ultimately you’re not deciding the case sensitiveness of databases, just of one database, and that’s the filesystem’s naming rules. The rules are arbitrary and conventional. Short of raw “any character code will always be different from any other character code regardless of how visually similar or grammatically interchangeable the user-facing glyphs may be” any other solution is just as arbitrary as each other. You’re always making a decision about it.
My contention is the decision shouldn’t be based on what is comfortable or more straightforward to implement, debug or use for the OS developers, it should be what is more usable by the lowest common denominator GUI-only users. And that’s case insensitive (but otherwise long and flexible) filenames.
Hardly, I’m directly addressing your statement that case insensitive is intuitive to users, grandmas or otherwise - I give examples where it’s not initiative or obvious which filenames match. I didn’t mention ease of implementation at all.
The principle of least surprise is an important UX consideration, and your idea of effectively introducing collation and localising which files conflict is just trading one problem for another set of problems and suprises (e.g. copying directories between drives with different settings).
No, it’s not. You’re substituting a base use case for an edge case and pretending they are on the same order when it comes to UX. They are not. File localization and mixing and matching alphabets in filenames is NOT the same as case sensitivity and using cases (or spaces, if we want to roll this conversation back a couple decades and talk about an actual implementation mess) in filesystems. Security and stability care about edge cases, it’s weird that you try to flex by name dropping “principle of least surprise” and then pretend that a problem impacting every single user who types a filename is the same impact on that than a user mixing and matching alphabets on multiple cases. ESPECIALLY when your example requires making the conscious decision that equivalent characters across alphabets is equivalent to case sensitivity, which is not a given at all.
Oh, and it’s not my idea. Default Windows and Mac FSs are case insensitive, legacy FAT systems are case insensitive. If the issue is standardization across systems, case sensistivity is the odd one out. If you’re having issues mixing and matching drives in older supported case-insensitive FSs the blanket fix for that is not having a case sensitive system elsewhere for no particularly good reason. I mean, speaking of minimizing surprise…