As explained before in #17765, is missing here the necessary code concerning Admin modules which language field does NOT depend on JLanguageMultilang::isEnabled() but on
$clientId === 1 && ModuleHelper::isAdminMultilang() as rightfully done in the Modules Manager
I proposed there to add a new layout to solve this issue
#17765 (comment)

looks like i missed a file from the commit @infograf768 I will update when I get home tonight

Not only the new layout but also a change to the edit.php (if this is what you did).

Please correct menu items manager.
languagefilter off gives:

I guess line 217 should only be
<?php if ($this->state->get('filter.client_id') == 0) : ?>

and line 254 should be
<?php if ($this->state->get('filter.client_id') == 0 && JLanguageMultilang::isEnabled()) : ?>

Also, the parameter show_associations has to be taken care of for articles.

For frontend we have to change 2 files

1. /components/com_content/Model/ArticlesModel.php line 690
   to if (\JLanguageAssociations::isEnabled() && $item->params->get('show_associations'))
2. /components/com_content/View/Article/HtmlView.php line 219
   to if (\JLanguageAssociations::isEnabled() && $item->params->get('show_associations'))

in both case it replaces if ($item->params->get('show_associations'))

For xml(s), the fields with name="show_associations" should only be proposed when JLanguageAssociations::isEnabled() both in front and back, including in the config.xml.

Thanks for testing - especially the front end which I forgot to look at. I will check those later. Also there was an email notification that template styles didnt work (I cant see that post now) but I am sure that was working as that was your code suggestion from the last pr

To test truely, I test on a multilang site where I set and unset the languagefilter.

I confirm that editing an article in frontend also still proposes language when languagefilter off
This could be solved by using the conditional in edit.php

			<?php if (\JLanguageMultilang::isEnabled()) : ?>
				<?php echo JHtml::_('bootstrap.addTab', $this->tab_name, 'language', JText::_('JFIELD_LANGUAGE_LABEL')); ?>
					<?php echo $this->form->renderField('language'); ?>
				<?php echo JHtml::_('bootstrap.endTab'); ?>
			<?php endif; ?>

That's how I was testing but I completely forgot the front end

Men items should be fixed now - the rest of the fixes will come later

Concerning the show_associations field display, it looks a bit more complex.
Here I had to modify ArticleModel.php. That one was easy.
Then I had to add a new fieldset layout for com_menus (that one looks hacky)
and I could not find a way to hide it in com_content config for now.

isnt show associations really beyond the scope of this pr as it is only supposed to show when associations is enabled or am i missing something

isnt show associations really beyond the scope of this pr as it is only supposed to show when associations is enabled or am i missing something

In our case, if the show associations field is set and we do have associations (for example from a former multilingual setting), then if language filter is set to off OR Associations set to off in the language filter, they still display in frontend, thus why we do need this code #18972 (comment) for frontend.

For the field itself, although it would have no effect on frontend display, it should be considered as the Content Language field and should not display at all when Associations is set to off in the language filter.

For example when editing an article we should add in getForm():

diff --git a/administrator/components/com_content/Model/ArticleModel.php b/administrator/components/com_content/Model/ArticleModel.php
index ebecc9a..f0ea5cb 100644
--- a/administrator/components/com_content/Model/ArticleModel.php
+++ b/administrator/components/com_content/Model/ArticleModel.php
@@ -387,4 +387,9 @@
 		}
 
+		if (!$assoc)
+		{
+			$form->removeField('show_associations', 'attribs');
+		}
+
 		return $form;
 	}

to get rid of the field.

When creating a menu item for com_content as well for the com_content Options, we shall also add some code to prevent the display of the field in the Options tab.

My point, and the reason that I think it is beyond the scope of this PR is, that associations should only ever be shown when the site is multilingual - the lnaguage filter plugin is enabled - and the option is set. There is no point in associations being shown at any other time. So if it is being shown when the site is not multilingual ie the language filter plugin is not enabled then it should be addressed in another PR at a higher level as its a different bug

Still, the fields should not display when the languagefilter is off (and therefore also the associations).
It can be done in another PR (where we would easily solve also the articles associations flags showing when the site has been switched from multi to mono language.)
That part is also to be solved in the 3.8.x series btw. Will look further what I can do.

See #19034 concerning the show_associations field

I have tested this item ✅ successfully on 1249529

Thanks :)

Woohoo . Thanks.