Personally I would like to use $app->getLanguageFilter(); everywhere and whole JLanguageMultilang class should be deprecated.

I was going to suggest to do exactly the opposite...

• the fact that we have there other methods in use as getSiteHomePages()

At first time I disagree with you but I can see it as:

• app is initialized
• app calls system plugins and our languagefilter
• the plugin sets language by JMultilang::setLanguageFilter(true); JMultilang::enable();
• now everybody can get boolean by JMultilang::getLanguageFilter(); JMultilang::isEnabled();

Personally I would like to use $app->getLanguageFilter(); everywhere and whole JLanguageMultilang class should be deprecated.

The admin app doesn't use that, only the site app. But JPluginHelper::isEnabled('system', 'languagefilter') can be used everywhere, as i proposed in PR #13159, but was rejected ....

Direct using JPluginHelper::isEnabled('system', 'languagefilter') is not a good idea because someone may want to write own plugin ex. languagefilter2.

@andrepereiradasilva how about setting one more flag (default = false) in the app, and then calling the plugin in the stack will change that value (if multilingual enabled) using JMultilang::enable(); ??

e.g. after https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/application/site.php#L28

First: as @csthomas, my opinion, is that JLanguageMultilang class should be deprecated and their methods moved to JLanguageHelper (if needed).

IIRC, there are 3 methods doing basicly the same thing ...:

• JApplicationSite::(get/set)LanguageFilter() https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/application/site.php#L591-L604
• JLanguageMultilang::isEnabled() the one in this PR
• JPluginHelper::isEnabled('system', 'languagefilter') that is a transversal method to check if any plugin is enabled.

This IMO is not the best scenario.

Direct using JPluginHelper::isEnabled('system', 'languagefilter') is not a good idea because someone may want to write own plugin ex. languagefilter2.

And? What is different from now?

@andrepereiradasilva how about setting one more flag (default = false) in the app, and then calling the plugin in the stack will change that value (if multilingual enabled) using JMultilang::enable(); ??

From an architectural point, why should the app have an hardcode dependency with the language filter plugin? Isn't it a plugin like any other?

First: as @csthomas, my opinion, is that JLanguageMultilang class should be deprecated and their methods moved to JLanguageHelper (if needed).

Agree

IIRC, there are 3 methods doing basicly the same thing ...:

JApplicationSite::(get/set)LanguageFilter() https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/application/site.php#L591-L604
JLanguageMultilang::isEnabled() the one in this PR
JPluginHelper::isEnabled('system', 'languagefilter') that is a transversal method to check if any plugin is enabled.

This IMO is not the best scenario.

Agree

Direct using JPluginHelper::isEnabled('system', 'languagefilter') is not a good idea because someone may want to write own plugin ex. languagefilter2.

And? What is different from now?

Use JLanguageMultilang::isEnabled() and JLanguageMultilang::enable() or better move that functionality to JLanguageHelper. I suggest methods like:
isMultilang() and setMultilang($enable = true)

Plugin at least need to call JLanguageHelper::setMultilang().

From now we can replace JLanguageMultilang::isEnabled() with JLanguageHelper::isMultilang()

@andrepereiradasilva how about setting one more flag (default = false) in the app, and then calling the plugin in the stack will change that value (if multilingual enabled) using JMultilang::enable(); ??

From an architectural point, why should the app have an hardcode dependency with the language filter plugin? Isn't it a plugin like any other?

IMHO should not.
Should only base on JLanguageHelper::isMultilang()

JLanguageMultilang::getSiteHomePages() probably should be move to somewhere...

Why change something that works perfectly and has always worked since it was implemented?
IMHO changing for the sake of changing is not a good idea.

IMO "works perfectly" is amatter of opinion, and is not equal to "not touch for ever".

The change proposed is not just for the sake of changing, i have better things to do than moving code around:

• IMO it's better from a code learning and arquitecture perspective, to have all language stuff in one place (ex: JLanguage and JLanguageHelper).
• We are making unnecessary db query in that function. We already can know from the following query if the language filter plugin is enabled.
  
• The current query does not check, for instance, the state or access of the language filter plugin, this leads to bugs
• Having all in one class is one more easy to mantain and less error prone than making hardcoded queries in the code

I was unclear in my comment. For me this PR is fine. I was commenting on the other proposals.

further analysing actually this PR will not work, because a user without access to language filter would not be able to see multilangue features.
So will close this