@Quy
Also did other combined queries, as much as I could do.
Could be missing some in the getStatus() method but I honestly think it would make the queries there more confusing than benefiting as we have multiple select.
Also I am not aware if we need or not to also change line 130 join and if we do as on line 123, if we should keep the ' AND ' as is.

May I suggest now to test the results of this PR rather than concentrating on the queries format as that type of format is absent from the majority of 4.0 code.

Done.

These are redundant.

The de-DE Content Language is trashed. It will not display on the site.

The Content Language de-DE is trashed.

These are redundant.

Good find! Corrected.

Still discussing with Mig about some display and content of messages.
Changes would be cosmetic.
So, can be tested but still WIP.

just a question. Is there a reason that we load this page in a popup and not a regular page

Is there a reason that we load this page in a popup and not a regular page

The reason was that it should be available at any time from any page of admin as some changes can have unwanted consequences on multilingual.

If it was created like the postinstallation messages wouldn't that satisfy that.

the reason is that the amount of information in the popup is getting quite large and it will be easier to display etc on a full page

It has absolutely nothing to do with postinstallation messages and comparing these is like comparing an apple to a bicycle.

Loading it like it is done for Postinstallation messages, which are usually only loaded once and can be hidden once read, is not what we want for this module as it would force to navigate again to where it was first needed by the user.
In 4.0, it may be a pain as, when using the default Preset menu, one may have to go through the System menu, etc.

Yes, when many aspects are wrong, it can become quite large. It is only because of the possible warnings. These important errors can be easily corrected grace to the informations provided which soon reduces the size. Scroll bars are there to be used if necessary.

This is working fine as is and makes it easier to inform users while preventing useless endless navigation.

Usability is the key word here.

It has absolutely nothing to do with postinstallation messages and comparing these is like comparing an apple to a bicycle.

I was referring to the location of the link

Loading it like it is done for Postinstallation messages, which are usually only loaded once and can be hidden once read, is not what we want for this module as it would force to navigate again to where it was first needed by the user.

Not if you set a return value

Yes, when many aspects are wrong, it can become quite large. It is only because of the possible warnings. These important errors can be easily corrected grace to the informations provided which soon reduces the size. Scroll bars are there to be used if necessary.

My suggestion removes the need for the scrollbar

Usability is the key word here.

Exactly which is why I make the suggestion

One is totally free to propose, once this PR is completed an d merged, another way to display these informations.
This is obviously not the purpose of this PR.

Now that I know there is no technical reason I will do

Added a new Error when the Default Site Language has no published Content Language.
As this would totally break the site, It is displayed as an Error on top of other warnings.
To test, unpublish, trash or delete the Content Language related to the Site Default Language.
You should get this:

The second part of the new message "If not corrected, the multilingual feature will not work!"
could be improved. Proposals welcome!

Changed new string to
COM_LANGUAGES_MULTILANGSTATUS_ERROR_DEFAULT_CONTENT_LANGUAGE="The Content Language for the <strong>%s</strong> default Site Language is unpublished or does not exist. <strong>If not corrected, the multilingual feature may not function properly or the site may not be reachable!</strong>"

Thanks Mig.

I guess it is now ready to go, as a module.

I have tested this item ✅ successfully on 605b87e

I have tested this item ✅ successfully on 0cc3ab8

RTC

Thanks

@brianteeman
I can make a new patch implementing what you wanted, with return when Close to the place where the Multilingual status was clicked.

Is that what you want?

That is almost what I was talking about - give me one sec

The url would be
index.php?option=com_languages&view=multilangstatus&return=xxxxxxxxxxx

without the template=component so that it looks to be part of the site

I will let you do it. I found some issues here doing it like this when switching to other menus without closing first the multilingual status module.

EDIT: also it lets click again on the module icon and we get into an endless loop as the redirect would now be the multilangstatus module path itself.

In any case the return is obtained by
$redirect = Uri::getInstance()->toString(); in the module default.php

ok - I will put it on my todo