avatar brianteeman
10 Dec 2018

This file was updated https://github.com/joomla/joomla-cms/blob/4.0-dev/templates/system/incompatible.html wih #23167
Is this an error or a change in policy?

<script>window.errorLocale = {"en-US":{"language":"English US","header":"Sorry, your PHP version is not supported","text1":"Your host needs to use PHP version {{phpversion}} or newer to run this version of Joomla","help-url-text":"Help me resolve this"},"en-GB":{"language":"English GB","header":"Sorry, your PHP version is not supported","text1":"Your host needs to use PHP version {{phpversion}} or newer to run this version of Joomla","help-url-text":"Help me resolve this"},}</script><!-- Sets the content of the translated text, IMPORTANT DO NOT REMOVE -->

avatar brianteeman brianteeman - open - 10 Dec 2018
avatar joomla-cms-bot joomla-cms-bot - change - 10 Dec 2018
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 10 Dec 2018
avatar mbabker
mbabker - comment - 10 Dec 2018

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.

avatar brianteeman
brianteeman - comment - 10 Dec 2018

so should this file be in the .gitgnore then ?

avatar mbabker
mbabker - comment - 10 Dec 2018

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).

avatar mbabker
mbabker - comment - 10 Dec 2018

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.

avatar brianteeman
brianteeman - comment - 10 Dec 2018

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

avatar mbabker
mbabker - comment - 10 Dec 2018

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

avatar dgrammatiko
dgrammatiko - comment - 15 Dec 2018

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

avatar infograf768
infograf768 - comment - 16 Dec 2018

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
avatar Bakual
Bakual - comment - 16 Dec 2018

@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.

avatar dgrammatiko
dgrammatiko - comment - 16 Dec 2018

@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...

avatar brianteeman brianteeman - change - 7 Jan 2019
Status New Closed
Closed_Date 0000-00-00 00:00:00 2019-01-07 19:40:15
Closed_By brianteeman
avatar brianteeman brianteeman - close - 7 Jan 2019

Add a Comment

Login with GitHub to post a comment