Note:
To install such file from a language pack, one has to add the folder hierarchy in the site folder part and add this in the site install xml, here for en-US

	<media destination="en-US">
		<filename>js/fields/calendar-locales/en-us.js</filename>
	</media>

@infograf768 you are perplexing things here imho. The old calendar (with it's language files) was on purpose left in place due to B/C and the case that someone could be using it. What you're trying to do here is mix the old way with the new. There is no need for us to fall back to a 10 year old convention. What will be far more interesting is: #19772 so we remove the edge cases for en-us and en-uk but also do it properly, eg all languages will have their own calendar strings file like el-gr.js.

I don't think so.
On one hand, I totally disagree with #19772 and I am not alone on this.
Also old and new ways are not at stake.
This PR lets override AND add new languages xx-xx.js files when they are not proposed by core.
Example:
I make a fr-CH lang pack for my own use and some strings have to be modified: I am NOT going to propose it to be included in core and I am not going to add manually a fr-ch.js in the media/system/ folder but rather in the proper fr-CH folder in the media folder.
This simple PR let's do that easily.

@dgrammatiko For your other PR, my comments are already there in that PR. But I honestly don't see how it would solve the issue JM is trying to solve here ("overriding" a language file that isn't present in core).

There is no need for us to fall back to a 10 year old convention.

Actually, it's neither a fall back, nor are 10 year old conventions bad per se. Imho it makes sense and it is in line with how we use the media folder for other extensions as well (put extension first and then inside the extension specific files). So I don't see the issue you have with this proposal at all.
But of course if you have a better proposal for a directory structure, I'm sure it can be adopted.

"overriding" a language file that isn't present in core

That can be fixed with the other PR. I guess you didn't actually realise what that code can do there...

That can be fixed with the other PR. I guess you didn't actually realise what that code can do there...

Whatever it can do (and we will test and decide later on what it really does) , this PR here is NOT for 4.0 but 3.x where this is not yet possible as stated by the author of the original Issue using customized regional languages.

Anyways for J4 I'll make a PR to utilise the native HTML5 date and time because most browsers already support it and it's easier to polyfill the ones (IE and Safari) that doesn't. Here's a rough preview (open it with FF): https://codepen.io/dgt41/pen/qYPZKa
Same thing for the input type="color". Let's stop trying to do our own crap implementation of things that are already widely supported from browsers these days.

But anyhow this is ok, I guess, if it will allow people to make easier overrides

Our own "crap" implementations predate the HTML5 tags and often still offer more functionality than most browsers native ones. So please don't be so harsh with previous contributions from both you and others. It paints a bad picture of you, not the others.
Of course, feel free to rewrite the calendar (yet again) for J4. Just make sure all the needed features are supported.

@infograf768 this looks like "rebase for J4".

I guess so as no one tested and I have not seen any noticeable change in calendar in J4, except now getting 2 files per language (at least for quite a few of them) in media/, a xx.min.js one added, which is totally useless imho for such small files.

Closed for rebase on J4.