Why would grandma need to specifiy the locale? The locale has been an environment variable set on install as far back as MS DOS and it is still that on Linux, Windows and Mac OS to this day, to my knowledge. You can tell grandma she can edit her config.sys if things aren’t working as expected, I suppose.
This is the second time someone spontaneously brings up non-latin alphabets as if they are equivalent to case sensitivity for no good reason. Who made a nerdy blog post about this and poisoned the well?
But to your question, case sensitivity is user-facing. That’s been my argument from the beginning.
You don’t need to care about the implementation side. You just need to care about how it’s used. If it makes more sense for the user to have File.txt and file.txt be the same, then that’s as much as you need to “understand” to have an opinion on this. A correct one, at that. The rest of it serves the user and the usability first.
To spell it out for you, very slowly: Casing is locale-sensitive.
You cannot determine whether file A and file B have the same case without taking the language the filename was written in into account.
Which means you need to somehow attach the locale to every file (name). Your browser could implement something to add that (semi-)automatically, but if grandma is creating a file from scratch, there is only so much you can do.
I hope this helps you understand why the thing you propose is stupid.
What thing that I propose? Case insensitive FSs aren’t a new thing. They are, in fact, the norm.
Why are you talking about this as if it’s a weird thing some rando in the Internet came up with? Yes, you need to attach the locale to the filename. No, I have no idea off the top of my head of how different file systems encode or store that.
I do know that the information is available, that it is handled in many commonly used FSs already… AND that you need to handle that anyway for a whole bunch of other reasons as well, from special characters ato alternate alphabets. And yes, there are edge cases (hey, to this day Windows won’t parse Japanese filenames out of the box half the time). That’s no excuse.
Once again, this is not about implementation, this is about the user-facing feature working as expected. “Oh, you can’t do case insensitivity because now you have to store additional information” is not an excuse to not support the feature.
Or, if it is, then let’s go back to eight characters from the English alphabet in all caps. 8.3 filenames. Why not? If we don’t want to have to implement features into the FS and convenience doesn’t trump having to deal with additional requirements and edge cases we may as well keep going. Why are spaces, cyrillic, special characters and long names worth doing but case insensitivity isn’t?
More precisely, they came up in a time where Unicode was not a thing.
Yes, you need to attach the locale to the filename. No, I have no idea off the top of my head of how different file systems encode or store that.
They don’t. None of them.
Or, if it is, then let’s go back to eight characters from the English alphabet in all caps. 8.3 filenames. Why not? […] Why are spaces, cyrillic, special characters and long names worth doing but case insensitivity isn’t?
Because you cannot have both.
It is either “spaces, cyrillic, special characters and long names” or case insensitivity.
OK, you’re going to have to be specific about your technical claims here. Which part of unicode support on filenames prevents case insensitive filenames?
I mean, I don’t know why you made me try, because I do use non-English characters day to day. But you made me try, and sure enough, you can absolutely mix and match alphabets and cases in NTFS and still have it behave case-insensitively. i.e. делоinsensitive.txt and делоINSENSITIVE.txt can’t be placed in the same folder and are parsed as the same name.
So if you have some bit of nuance about why you “cannot have” the feature that clearly works right now in front of me in my computer and has for ages I’m all ears. For a completely impossible implementation of a clearly useful feature it sure seems like it is actively supported in most of the FSs currently in use.
EDIT: Made me go check because now I’m curious about the edge cases you guys keep claiming are catastrophic. Putting those two files in a case sensitive Samba share an opening it in Windows keeps the mix of characters but a suffix gets unceremoniously appended to the filename of one of the files. That’s probably a bit of a mess in some circumstances if you don’t know it’s coming, but there you go.
So every time grandma picks a file name she needs to specify the locale?
What a stupid hill to die on.
Why would grandma need to specifiy the locale? The locale has been an environment variable set on install as far back as MS DOS and it is still that on Linux, Windows and Mac OS to this day, to my knowledge. You can tell grandma she can edit her config.sys if things aren’t working as expected, I suppose.
This is the second time someone spontaneously brings up non-latin alphabets as if they are equivalent to case sensitivity for no good reason. Who made a nerdy blog post about this and poisoned the well?
Why do have such a strong opinion on things you –rather obviously– understand very poorly?
Yeah, maybe figure this one out for yourself to get you on track for learning something.
That sentence makes no sense. You don’t have to agree on things, but at least be coherent in your objection.
Seriously, I will find that blog.
But to your question, case sensitivity is user-facing. That’s been my argument from the beginning.
You don’t need to care about the implementation side. You just need to care about how it’s used. If it makes more sense for the user to have File.txt and file.txt be the same, then that’s as much as you need to “understand” to have an opinion on this. A correct one, at that. The rest of it serves the user and the usability first.
What blog?
To spell it out for you, very slowly: Casing is locale-sensitive.
You cannot determine whether file A and file B have the same case without taking the language the filename was written in into account.
Which means you need to somehow attach the locale to every file (name). Your browser could implement something to add that (semi-)automatically, but if grandma is creating a file from scratch, there is only so much you can do.
I hope this helps you understand why the thing you propose is stupid.
What thing that I propose? Case insensitive FSs aren’t a new thing. They are, in fact, the norm.
Why are you talking about this as if it’s a weird thing some rando in the Internet came up with? Yes, you need to attach the locale to the filename. No, I have no idea off the top of my head of how different file systems encode or store that.
I do know that the information is available, that it is handled in many commonly used FSs already… AND that you need to handle that anyway for a whole bunch of other reasons as well, from special characters ato alternate alphabets. And yes, there are edge cases (hey, to this day Windows won’t parse Japanese filenames out of the box half the time). That’s no excuse.
Once again, this is not about implementation, this is about the user-facing feature working as expected. “Oh, you can’t do case insensitivity because now you have to store additional information” is not an excuse to not support the feature.
Or, if it is, then let’s go back to eight characters from the English alphabet in all caps. 8.3 filenames. Why not? If we don’t want to have to implement features into the FS and convenience doesn’t trump having to deal with additional requirements and edge cases we may as well keep going. Why are spaces, cyrillic, special characters and long names worth doing but case insensitivity isn’t?
More precisely, they came up in a time where Unicode was not a thing.
They don’t. None of them.
Because you cannot have both.
It is either “spaces, cyrillic, special characters and long names” or case insensitivity.
OK, you’re going to have to be specific about your technical claims here. Which part of unicode support on filenames prevents case insensitive filenames?
I mean, I don’t know why you made me try, because I do use non-English characters day to day. But you made me try, and sure enough, you can absolutely mix and match alphabets and cases in NTFS and still have it behave case-insensitively. i.e. делоinsensitive.txt and делоINSENSITIVE.txt can’t be placed in the same folder and are parsed as the same name.
So if you have some bit of nuance about why you “cannot have” the feature that clearly works right now in front of me in my computer and has for ages I’m all ears. For a completely impossible implementation of a clearly useful feature it sure seems like it is actively supported in most of the FSs currently in use.
EDIT: Made me go check because now I’m curious about the edge cases you guys keep claiming are catastrophic. Putting those two files in a case sensitive Samba share an opening it in Windows keeps the mix of characters but a suffix gets unceremoniously appended to the filename of one of the files. That’s probably a bit of a mess in some circumstances if you don’t know it’s coming, but there you go.
No, I’m not going to waste further time on trying to make you understand things you are not capable or interested in understanding.