It will need to update the list of files to be deleted in script.php so that the files with old names are deleted on update.

But this does not need to be done in this PR here.

We (@wilsonge or me) just have to remember to run the tool to generate the list and then make that change before making the release after this PR has been merged. If George gives me the necessary time after this PR has been merged, I will do that.

Some renamings was from lowercase to camel case (example sr-rs => sr-RS ), not sure how it will be handled during update.

That's another thing I will do with the tool mentioned in my previous comment. It will handle that renaming, too, in a routine at the end of script.php..

@Fedik Alternatively, if someone insists on the file delete and rename stuff in script.php do be done in this PR, I can run the tool using this branch and make a PR for you.

@conconnl can you have a look at the missing translation, should we keep them only in the CMS? could be tricky to sync or should we move them to core-translations too?

thx @Fedik
@richard67 I think the delete (is the big clean PR already merged?) and the rename (or at least the rename) script should be in this PR.

@richard67 I think the delete (is the big clean PR already merged?) and the rename (or at least the rename) script should be in this PR.

@HLeithner What do you mean with "the big clean PR"?

@HLeithner I don't understand what you are asking!
The JS file is not uploaded to the Crowdin source list, as it was required by various production members.
The file was coming from TinyMCE or something. It was even planned to be removed from the GitHub repository.

If the file needs to be translated, we can add it too the source folder. It must be stated how the translated files need to be exported. This can be in the "nl-NL" or "nl" method or others.

I just found a couple files with broken JS:

ca-ES.js (totally broken)
el-GR.js
ro-RO.js

I have fixed them here, but they need to be fixed in core-translations also

The file was coming from TinyMCE or something.

@conconnl it is Calendar localisation files, nothing for TinyMCE

Sorry to ruin the party here but...

The js files were introduced in 3.x version when we redid the calendar so we wouldn't break B/C. For J4 are not needed, eg pass a json as an attribute to the calendar element and grab it in the js (or pass the strings as Text strings, even easier). Something to consider...

Well, yea, can build it from existing language strings:

...
days => [Text::_('SUNDAY')], Text::_('MONDAY') ....]
...

Maybe will be need to add some constants.

Language::getFirstDay() and Language::getWeekEnd() we already have.

So we do not need to maintain bunch of files.

@Fedik Before I invest time for making a PR for deleted and renamed files in script.php: Will there be changes on this PR due to @dgrammatiko 's feedback, e.g. removing all those calendar locale js and at the end the complete folder? If so, I should wait for that.

@richard67 wait with that,

I can try make that changes (in separated pr so we can compare)

First I need to know what @HLeithner and @conconnl will say about it :)

If the JS files technically aren't needed, we certainly should drop them in favor of INI files and use that approach. Would make things a lot easier for all ?

@Bakual no no! everyone should learn JS! ?

The file was coming from TinyMCE or something.

@conconnl it is Calendar localisation files, nothing for TinyMCE

Oke, I just configure the settings required and advised by Production. It’s for now completely disabled. If the conclusion now is that it needs to be enabled, uploaded to Crowdin, being translated, I can do that in minutes (when I’m back home) Just need to know what the file result needs to be. nl.es5.JS or nl-NL.es5.JS

To be clear, the files in the repository now are just the backup from the old Crowdin system where a few lines were translated for this file and the naming was done as you see them now. They are probably not fit for use at this moment.

@Bakual no no! everyone should learn JS! ?

It's not like one would learn JS just from that locale file ?

if you ask translator to fix this file https://github.com/joomla/core-translations/blob/main/joomla_v4/translations/core/build/media_source/system/js/fields/calendar-locales/ca-ES.es5.js

he definitely will learn the object syntax at least :)

Okay, please do not merge this PR for now,

I will look how to make it without extra files, so maybe we can drop them.

I will look how to make it without extra files

@Fedik may I propose to use data-attr for the calendar-type (gregorian/etc), first-day, weekend, and pass all the other strings using the Text obj?

yea, it will be something with data- ;)

okay, it will be harder than I expected, the config also hardcoded in to date-helper.js,
well, will take some more time

@Fedik Maybe change this PR back to draft status so people don't test?

That's a bit of a bleak situation, moving to ini syntax now would break the language freeze. Postpone the move to 4.0.1 or 4.1 would create an b/c break. Not really sure if this would really be a b/c break because it's no a public api and we ship the files our self.

Do we have all needed translations in the ini file?

Looking at the german translation I don't think we have translations like dateType, weekend, exit and clear. Also AM and PM doesn't make sense in german normally ;-)

	today : "Heute",
	weekend : [0, 6],
	wk : "KW",
	time : "Uhrzeit:",
	days : ["Sonntag", "Montag", "Dienstag", "Mittwoch", "Donnerstag", "Freitag", "Samstag"],
	shortDays : ["Son", "Mon", "Die", "Mit", "Don", "Fre", "Sam"],
	months : ["Januar", "Februar", "März", "April", "Mai", "Juni", "Juli", "August", "September", "Oktober", "November", "Dezember"],
	shortMonths : ["Jan", "Feb", "Mär", "Apr", "Mai", "Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"],
	AM : "AM",
	PM :  "PM",
	am : "am",
	pm : "pm",
	dateType : "gregorian",
	minYear : 1900,
	maxYear : 2100,
	exit: "Schließen",
	clear: "Leeren"

I looked into the PR more in deep now and saw many errors in the translation and also completely missing translations.

I would suggest to move everything in the calendar locals to it's own ini file and remove the js files completly, also creating a json object for data-attribute sounds like a good idea.

if we do this in 4.0 or 4.0.1 or 4.1 or 5.0 is up to @wilsonge and @bembelimen

That's a bit of an bleak situation, moving to ini syntax now would break the language freeze. Postpone the move to 4.0.1 or 4.1 would create an b/c break. Not really sure if this would really be a b/c break because it's no a public api and we ship the files our self.

This whole mess is my fault. I'm sorry, I should have pushed the JS Team for the changes back in the day.

The situation is not that bad though, most strings already exist in the ini's and then there are some that should be coming from the language xml, eg calendar type (gregorian, etc), first day of the week, weekend days. All and all the impact is 4-5 strings added...

This whole mess is my fault. I'm sorry, I should have pushed the JS Team for the changes back in the day.

It's not important who and if it's someone fault

The situation is not that bad though, most strings already exist in the ini's and then there are some that should be coming from the language xml, eg calendar type (gregorian, etc), first day of the week, weekend days. All and all the impact is 4-5 strings added...

The main problem is we need someone who is motivate to fix it.

I have started already, I will make separated PR for it, so we can look how it will affect.
But it will take some time.

Looking at the german translation I don't think we have translations like dateType, weekend, exit and clear. Also AM and PM doesn't make sense in german normally

It not all need to be language constants, example dateType is config option, same for week, max/min year.
But stuff like AM, PM, today, will be a new strings, and maybe some others, I not checked all (for now).
Days constants we already have somewhere in INI files, they can be reused.

@Fedik can you share your branch?

Yes, when will have a visible progress ?

there PR with use of existing lang strings #34870
please review

Just a note of interest: I have a custom component that uses 16 Site languages. In recoding for J4 I switched from a jQuery calendar to the J calendar and assumed it would be all right on the night.

Just a note of interest: I have a custom component that uses 16 Site languages. In recoding for J4 I switched from a jQuery calendar to the J calendar and assumed it would be all right on the night.

This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/34819.

so you tested and it is all right or do you miss anything?

So is this abandoned for now? I just noticed that nl was to be replaced by nl-BE - so what about nl-NL?

@ceford these files does not need anymore,
look #34870