It would rather be class="associated"
But I guess your mockup includes some changes to the module to check if we have or not a direct association for that language link.
If you have done that code, please share.

To me the language switcher does what it's supposed to do: switch language. In some cases there are translations to the page available, in some not. How would you explain those colours to the visitor?

Why not add a possibility to add "This is also available in French(FR) / German (DE)" to the content item? e.g. in an article and on a blog category list for each article item? The article might be translated and associated but not the category.

Please forget the term "Translated". "Associated" items MAY be a translation... or not.
@schnuti
I think this should done by a specific plugin. This is not the work of the switcher. The code should be inserted, depending on the template, at specific places when displaying an associated item whether alone or in a blog/list.

@infograf768
Exactly, that was what I tried to say. Coloured links do not help me much. And with flags for the language switcher? Coloured background?

I don't ask for colours or other, I just ask that the language module gives the information with a class (I agree with @infograf768 that associated is a good name).

I'm not fixing the ergonomic in any way, it's up to the template designer to decide what to do with this. The example I show was just a live modification of the CSS with firefox to have an idea of the matter.

It can be done by a plugin but in some way it means doing twice what the language module is already doing. While it have this information, why not let it be available. I mean we can introduced this class without using it, its just an option to the skin designer (also usable by a javascript, to split entries or so, or just to hide non associated with css…).

Again it's not about choosing how to display the information but just giving it, while we have it (and this is fully in the logic of what is done with the "lang-active" class).

I agree with you, if it was that easy.
Did you have a look in the code? I did but I do not have a multilangual Joomla instance to test with at the moment.
As far as I know, the link comes from the components HelperRoute without any indication what it returns, match or not. I wouldn't change my own code for this.
You could of course run a new match in the language switcher.
I look forward to see the code.

It is not as easy as it seems.
A very common situation is to have 2 menu items (or more) associated. Let's say these are list or blog. Then one would have among the items some directly associated and others not.
The class added could therefore depend of the type of association. Until then, fine, we could add specific classes "compassoc" and "menuassoc" in the module helper and call them in the tmpl. In some cases we would therefore get 2 classes added in the module.
If a the category is also present in the equation, note that we can't differentiate in the module between an item and a category.

Although I think it is useless in the module, the code is pretty simple.
In the helper:

                if ($multilang)
                {
                    $language->assocClass = '';

                    if (isset($cassociations[$language->lang_code]))
                    {
                        $language->link = JRoute::_($cassociations[$language->lang_code] . '&lang=' . $language->sef);
                        $language->assocClass = "associated";
                    }
[...]

in the tmpl:

<li class="<?php echo $language->active ? 'lang-active' : ''; ?> <?php echo $language->assocClass; ?>" >

and we would get

A somehow better solution I see is to try to propose a new feature in core for 3.7 where the flags would show next to the item or category display depending on new parameters.
This is more complex though...
Mock-up

Good idea, the second! It corresponds with our "plugin" method, doesn't it? Much better if it's directly included in the basic code. Do you also mean to include the flags for the single items in e.g. a category list?
To add classes in the module get very complex. I can think of many variations. e.g. a link to a menu item can be as "correct" as a link to a category or an article (or the other way around). You might also get other results with 3.pd extensions, who knows.

Ok I surrender, this is not so evident ! The language module is working on the site settings, while adding association is about the content.

Thanks however for I didn't realize that association where directly in the content, so I should grab them quite easily in my case where I mostly care about categories and articles association.

A thorough implementation would have to check the content status (published or not), but I won't care !

@infograf768 I don't know if you want to keep that issue opened ? Feel free to close, for me it's over.

Closing at this time.

Hello can we re-open this ?

I looked at the code and all is there for this small improvement, I'll make a PR.

No need to reopen it as you have created a PR

For the exercice I also implement the functionality as a module but it required a lot of copying from mod_language. So I think having it in mod_language is a better idea.
https://github.com/alexgarel/joomla-show-translated

@schnuti @alexgarel

Please test
#11935