Databases have different case-insensitive collations - these control what letters are equivalent to each other. The fact that there’s multiple options should tell you that there’s no one-size-fits-all solution to case insensitivity.
This issue is only simple and obvious if you don’t know enough about it.
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…
Thanks. That is what I’d expect, and highlights the disconnect I saw in this comment chain: I think what some other folks were trying (less-than-artfully) to say is that there’s a difference between what one might expect case-insensitive means as a computer programmer, and what one might expect case-insensitive to mean in human language. All three of those should be the same filename in fr_FR locale, since some French speakers consider diacritical marks to be optional in upper case. While that might be an edge case, it does exist. English is even worse, with a number of diacritical marks that are completely optional, but may be used to aid legibility, e.g. café, naïve, coöperation. (Whether that quirk is obvious or not, or whether it outweighs any utility of case-insensitivity is not something that I have a strong opinion on, though.)
Whaaaat? You’re telling me someone in the Linux community chooses to be deliberately obscure based on a technicality no end user cares about in a patronizing, elitist manner?
Naah. Impossible.
The issue with the special characters for accent marks and diacritics is their importance fluctuates per language, so you have to keep them separate unless you want to make different rules per locale instead of per character.
They do it the other way for number formatting and that’s already a mess. If you’ve ever tried to work with spreadsheets across locale formats it’s absolutely bonkers. Excel outright changes the separators in formulas.
Are these the same filename?
What about these?
Databases have different case-insensitive collations - these control what letters are equivalent to each other. The fact that there’s multiple options should tell you that there’s no one-size-fits-all solution to case insensitivity.
This issue is only simple and obvious if you don’t know enough about it.
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 don’t have Windows here to test, so I keep wondering, are all of these forms the same?
On a NTFS drive on Windows with default settings the first two are the same, the third one is not.
Caps and non-caps are matched, accented/unaccented characters are not, which is probably what you’d expect.
Thanks. That is what I’d expect, and highlights the disconnect I saw in this comment chain: I think what some other folks were trying (less-than-artfully) to say is that there’s a difference between what one might expect case-insensitive means as a computer programmer, and what one might expect case-insensitive to mean in human language. All three of those should be the same filename in fr_FR locale, since some French speakers consider diacritical marks to be optional in upper case. While that might be an edge case, it does exist. English is even worse, with a number of diacritical marks that are completely optional, but may be used to aid legibility, e.g. café, naïve, coöperation. (Whether that quirk is obvious or not, or whether it outweighs any utility of case-insensitivity is not something that I have a strong opinion on, though.)
Whaaaat? You’re telling me someone in the Linux community chooses to be deliberately obscure based on a technicality no end user cares about in a patronizing, elitist manner?
Naah. Impossible.
The issue with the special characters for accent marks and diacritics is their importance fluctuates per language, so you have to keep them separate unless you want to make different rules per locale instead of per character.
They do it the other way for number formatting and that’s already a mess. If you’ve ever tried to work with spreadsheets across locale formats it’s absolutely bonkers. Excel outright changes the separators in formulas.