IIRC the logic is that the compiler crawls all of the installation language files and extracts the keys needed for the static HTML pages so those are displayed with localized text where supported (en-GB and en-US being the only locales in 4.0's installer at the moment).

As far as the JSON string actually changing, it's an inconsistency in the compiler. I've seen it frequently flip the en-GB and en-US keys, it'd be nice if that were always consistent.

so should this file be in the .gitgnore then ?

No. https://github.com/joomla/joomla-cms/blob/4.0-dev/templates/system/build_incomplete.html and https://github.com/joomla/joomla-cms/blob/4.0-dev/templates/system/incompatible.html are both there to give output when there are environment issues (PHP version too old or NPM/Composer installs incomplete) and point folks to useful pages, ignoring these would mean you'd never get the build_incomplete.html page which defeats the purpose of it existing in the first place (it's less of an issue for the PHP version check/file, that could be flipped back to printing a line of text like it does in 3.x).

If the issue with the inconsistent key ordering were resolved realistically the only times you should see updates to those files are when the root template changes or the language strings are added/updated.

Either way it should be en-GB not en-US unless there has been a policy change

Both en-GB and en-US are in that output...

FWIW @mbabker is right, also the inconsistency I gues is coming from the file system: the script is crawling the languages folder but there is no guarantee that the result will be a-z. If that’s a real problem, imho it’s not, we can provide the languages in an array in the settings.json so no more inconsistencies but more code to pamper

Could I have some more input on this?
What is supposed to happen when another language is

1. Present in the installation folder and the error is displayed when trying to install. Case: that language is set as preferred language in localise.xml <forceLang></forceLang>
2. Installed in the site and admin folder and the error happens when loading any of these. Case: that language is set as default and the php version has been changed to one < 7.0

@infograf768 That file will support all installation languages which were present at the time when the release pack was created.
Site and admin folders don't matter at all.

@infograf768 these 2 pages are plain HTML, and since PHP was not really ran our only chance to provide some meaningful translation is by using javascript. When I first introduced this feature the translations were a separate js file but this was not working for sites installed in a subfolder (bad practice imho) and thus I refactored the build script so that the script data now is inlined. The whole thing is pretty well automated as is right now and it only requires some specific strings in the installation languages. The question from Brian is why do we end up with multiple commits with only difference the order of the languages.

Now that I'm rethinking this I guess setting the html in the system template was wrong, the HTML files should be stored somewhere in the media folder...