@infograf768 can you see this one? is this a bug?

It is true that any module or component containing JHtml::_('formbehavior.chosen', 'select'); (not only mod_languages) will force all select boxes on the site to also display as chosen.

It is also true that this should be the choice of the template to decide or not to implement chosen.
This obvioulsy can be decided by overrides, mod_languages included.

Example using Protostar:
If I take off JHtml::_('formbehavior.chosen', 'select'); from mod_languages and I edit an article or edit a module (frontend) or display smartsearch, mod_languages dropdown will still be displayed with chosen as chosen is loaded by these.
If we follow this proposal (the code proposed works fine. I used mod_languages_select with an s), if nothing is loading chosen in frontend, mod_languages will be alone to use chosen.

I consider the possible proposed patch to \layouts\joomla\html\formbehavior\chosen.php a good new feature in any case.
If we do and PLT is in favour, then It would be sensible to not only patch mod_languages but all core tmpl using chosen.

My personal feeling is that a template designer should decide globally if chosen should or not be used for the template and make the overrides accordingly.

After some discussion with @roland-d I found we have a much simpler solution for example with mod languages:

diff --git a/modules/mod_languages/tmpl/default.php b/modules/mod_languages/tmpl/default.php
index 83e5f2a..414d18e 100644
--- a/modules/mod_languages/tmpl/default.php
+++ b/modules/mod_languages/tmpl/default.php
@@ -13,5 +13,5 @@
 if ($params->get('dropdown', 1))
 {
-   JHtml::_('formbehavior.chosen', 'select');
+   JHtml::_('formbehavior.chosen');
 }
 ?>
@@ -23,5 +23,5 @@
 <?php if ($params->get('dropdown', 1)) : ?>
    <form name="lang" method="post" action="<?php echo htmlspecialchars(JUri::current()); ?>">
-   <select class="inputbox" onchange="document.location.replace(this.value);" >
+   <select class="inputbox advancedSelect" onchange="document.location.replace(this.value);" >
    <?php foreach ($list as $language) : ?>
        <option dir=<?php echo $language->rtl ? '"rtl"' : '"ltr"'; ?> value="<?php echo $language->link; ?>" <?php echo $language->active ? 'selected="selected"' : ''; ?>>

hello, let me explain the background:

we are developers of various extensions running on joomla and the "default mod_languages" template breaks our select drop downs. i know this can be handled via template overrides, but it's quite complicated or impossible to fix this once our customers install our extensions. what you propose is that we would automatically install the template mod_languages file to change the chosen selector to be more exact (using classes) and not that generic (using element type).

the fix in chosen.php is intended to fix a javascript error IF THE SELECTOR FAILS and returns no items for any sort of reason.

you are right, that there are more ocurrances of this code within the core joomla, but if they are loaded from components, the effect is not that destructive as if they are loaded from a module shown on every site's page.

other modules that include such generic loader for the chosen are:
mod_finder

everywhere else it's loaded within components' backend which should be all okay. we also use chosen within our extensions, but it's always crafted to meet the purpose:

• either for multi selects
• either for ajax driven searches
• we strongly do not recommend to use it on mobile devices, since the browsers native rendering works much better

best regards, stan

Also, advancedSelect is default, but we can use anything without changing the library:

if ($params->get('dropdown', 1))
{
    JHtml::_('formbehavior.chosen', '.mod_languages');
}

<select class="inputbox mod_languages" onchange="document.location.replace(this.value);" >

will also work as it is $selector that counts.

i actually like the advancedSelect class which does the job and makes it quite consitent.

This is what I propose:

I have seen the issue for mod_languages, smartsearch (finder) and edit modules in frontend.
I will try to make a patch for these.

In the meanwhile, you can propose a PR for the library as it would be independant.

PR here #9671

please test

Note: Edit modules (frontend) is not in the scope of this PR.

Closed as we have a Pr for testing - thanks