PS There is one more thing that needs to be automated: tinyMCE's languages

Tested and it works as described.
But why are we doing it like this? For me it is more confusing to have calendar-field specific language strings in the installation folder.

You are touching the wrong language file. The one in the installation folder obviously is only available during the installation. You should be targeting the two main en-GB.ini files in both /languages and /administrator/languages

also you should only touch the en-gb files. Every other language should be handled by the TT only

For me it is more confusing to have calendar-field specific language strings in the installation folder.

Well yes, if we go by the book and want to separate concerns the installation language folders should have two more files:

• for the php error page
• for the calendar

I think this is mostly implementation detail which can be very easily changed. The main idea is to create the static (.js) files through our build tools.

You are touching the wrong language file

Nope this was done in purpose

also you should only touch the en-gb files. Every other language should be handled by the TT only

The idea is that J4 will finally get a centralised language distribution instead of the current one where each Language specialist needs to pack the language file. Moving to Crowding was a step into that direction and this PR is just an tiny addition for that.

The installation ini files will be deleted (as well as the whole installation folder) after install.
What happens when someone is upgrading a j3 site to J4? OR a j4 .x to j.4.y where new languages are available?
A new language pack which does not yet have the installation ini file in core will not get the desired ini strings.

where has this idea been discussed?

I have tested this item ? unsuccessfully on 77b69b6

I think this is mostly implementation detail which can be very easily changed. The main idea is to create the static (.js) files through our build tools.

Got it. So it will make the work for translators easier ? But i find it still very confusing that you used the installation folder and the installation cmd for this. We should probably create a special command npm run generate:calendar-locales and use a better suited place in project structure for this.

Just sayin: would also be possible to do this in php (as it is still the main project language)...

php is not the main project language. We use ini files, except for these 2 js files (calendar and tiny).
Let me also add that we do have already many js files for much more languages than we will get for 4.0 and that it is not a big deal to gather them when/if we get some new ones.
What "could" be done is judged necessary is to add a new xx-XX.lib_calendar.ini in both site and administrator, but it would mean that joomla would have to check/create the possible resulting js files each time the site is loaded.

php is not the main project language

Err, code metrics disagrees...

(Yes INIs are the project's main translation format, not to be confused with the primary programming language used for building the software)

That was not necessary. We were here talking about language files format (which is not necessarily translation as en-GB is the default), and not the CMS language.

I have tested this item ? unsuccessfully on 77b69b6

*sigh* Have you actually reviewed what this PR is doing?

Instead of asking the translation teams to produce JavaScript files for the calendar integrations, this moves the translation strings into the INI files for the installation application (since every core supported language must have one) and adds some code to the repo to automatically extract those translations into the correct JavaScript files. So is this a disagreement in principle or is there an issue we are missing here?

What was not clear from the OP I now understand as the following - please confirm if this is correct

• The calendar language files will live in the main .ini files in the installation folder
• The installation folder was chosen because it is the only folder in the filesystem that has subfolders for each language supported by joomla
• The script will generate the required js files and copy them to the correct place in the media folder and this will be done before a package is released (just like the build.php script)

If that is correct then

• I would use a new parent folder for these non-distributed language ini files (i think that is what @dneukirchen was saying about confusion)

My only other concern/confusion is when the build script is run and the files generated as we really should be ensuring that the version of joomla on github can be downloaded and installed on a server without extra steps.

One operational change is that we would no longer be able to allow a TT to only create a front end language??

oh and this would force every content language to also be available as an installation language which we dont enforce currently.

PS There is one more thing that needs to be automated: tinyMCE's languages

I wouldn't touch Tiny as those files actually are 3rd party files. We usually take the existing Tiny translations from Transifex (I think). Converting them to our own INI files just adds work for no reason.

The idea is that J4 will finally get a centralised language distribution instead of the current one where each Language specialist needs to pack the language file. Moving to Crowding was a step into that direction and this PR is just an tiny addition for that.

Crowdin is able to deal with the JS files. They need to be translated "offline" but Crowdin can manage them.

That being said, the idea of moving the strings to an INI file for translation and building the JS from there is nice. But the points raised by Brian need to be solved first.

• I need to be able to clone that repo and get a functioning CMS without first run a build script. Which means the generated JS files need to be in version control itself and the generation needs to happen after every change in installation language files.
• Personally I would put those calendar INI strings in an own file, best in an own folder (eg in build folder). Not misusing the installation INI file. While I understand the goal to simplify it for translators, it actually only confuses. With Crowdin it doesn't matter anyway where the file is located.

Looking at the initial goal of making stuff for translators easier, I'm not sure if that goal really is met. Yes it's a bit easier for translators using Crowdin since they can translate it in the web editor directly. However translating the JS file offline and uploading the finished one isn't hard or complex work either. We're talking about 17 simple strings here.

Ah and of course currently we don't need to duplicate work for dialects of languages. Eg en-US uses the same en.js file as en-GB uses. Same for the german languages.
With your PR as I understand it the strings need to be translated for each language dialect.

I guess nobody read what I stated above...

What happens when someone is upgrading a j3 site to J4? OR a j4 .x to j.4.y where new languages are available?
A new language pack which does not have the installation ini file in core will not get the desired ini strings.

once the installation folder is deleted, which would be the case when updating a site, no js created for the new language...

@infograf768 read my comment here #19772 (comment)

ok, i understand now. i agree with @Bakual ‘s comments.

@infograf768 we don't care for the ini files IN joomla installation to be delivered. The folder was chosen because:

• it contains all the supported languages
• we already using this method for the PHP unsupported pages

no js created for the new language...

The js files are created by the maintainers not the final user

With your PR as I understand it the strings need to be translated for each language dialect

This can be fixed

it contains all the supported languages
Not necessarily

Honestly it just complicates things. They should be in their own files in their own folders. If they had then there would have been no confusion here at all ;)

I would use a new parent folder for these non-distributed language ini files

@brianteeman could be done that way, as I said before the actual implementation here is not take it or leave it, rather more showcasing the possibilities.

Basically I would like to automate as much as possible all the repeated, silly tasks.

PS About tinyMCE, there is an API to get each language file, I never thought of putting extra load to the translators. So to make this clear right now the tinyMCE languages have no known procedure for updating (unless if someone thinks that comparing the local folder with the remote folder for each version is a task that doesn't need improvement). Having one command to auto update all these files is a great improvement for maintainability of our codebase...

Basically I would like to automate as much as possible all the repeated, silly tasks.

Umm, there is actually no repeated, silly task here that you want to remove. Beside the occasional merging of new JS files. But that can be automated by Crowdin already if we wish to do so.
Imho, you're trying to solve an issue that doesn't exist.

About tinyMCE, there is an API to get each language file,

Sure. But then you miss out on the verification done by our language teams. From what I hear the translations of the official TinyMCE sometimes are lacking. We try to improve them of course by fixing it upstream but it's not guaranteed to get accepted.
Also we have to change the locale in the files to match our codes.

So to make this clear right now the tinyMCE languages have no known procedure for updating

There is a procedure, the same as for each other language file change. If there is a change in the english file, TTs are notified and they fetch, verify and post the updated file. Yes there is manual processing here which includes a quality check and some custom changes. However the updates really aren't that often and I haven't heard a single complaint from TTs so far.
Honestly, automating something which rarely happens and doesn't take much time is quite pointless in my eyes. Lets automate the task which happen often and are time consuming (eg releases) and make those simple to use. Don't overengineer stuff.

Obviously this won't fly