Nice @Bakual ! Thanks for doing this. Will test tomorrow.

Like Andre, great and thanks for this... Hope being able to test it tomorrow.

I have tested this item ? unsuccessfully on 08b336a

I have tested with 3 languages (en-GB, fr-CA and fr-FR WOITHOUT image)on fresh install and few unexpected behaviors happened.

All menu items view, it looks fine:

Content languages and templates also:

For other views, nothing seems to appear:
(tested Contact, modules, cat, articles)

i tested this. All seems fine except:

1 bug in contacts:

Lack of uniformization. Sometime the language code is used, another times the language sef is used.
IMHO the language code should always be used

Besides the comments above IMHO the new layout needs to be also applied in com_weblinks repo

@MATsxm That is strange, it looks like this for me:

Can you try with error reporting enabled? Maybe there is some error hidden there.
And also check if the file /layouts/joomla/content/language.php is present. It should look like this: https://github.com/Bakual/joomla-cms/blob/no-lang-image/layouts/joomla/content/language.php

@Bakual
TBH, I suspect a problem while applying the patch.
I'll try on a new install later today.
Thanks

@andrepereiradasilva Yes, if this is merged, the Weblinks should be adjusted as well.
The contacts bug should be fixed now. I missed the helper function there.

As for the inconsistency, the thing is that the language code (en-GB) would look very ugly on that "home" button or in the menu because it is much longer. I've also used the same as is already been used in the association labels.
For the association tooltip I have settled for the language code because the SEF code is already present below the tooltip. Changing that to SEF doesn't make sense as it would be redundant information. We could completely remove it if we want.

As for the inconsistency, the thing is that the language code (en-GB) would look very ugly on that "home" button or in the menu because it is much longer. I've also used the same as is already been used in the association labels.

But if you have a sef 'de' and other 'de-ch' it would look even "uglier".
Also you used the language code in other places

I still think is more correct to have the language code than the SEF. The sef can be anything the user wants, the langauge code must respect iso.

For the association tooltip I have settled for the language code because the SEF code is already present below the tooltip. Changing that to SEF doesn't make sense as it would be redundant information. We could completely remove it if we want.

reggarding association tooltip an idea would be to improve it like we did in GSOC multilingual project. Example:

See https://github.com/joomla-projects/gsoc16_improved-multi-lingual/blob/staging/administrator/components/com_associations/helpers/associations.php#L498

that way you don't even need to use the language code or sef. in this case we could just add or not the flag if exists as you do in the language columns

In the module assignment I just went with the data that was available. ?
In the other places I think it makes more sense to use the same code like it is already used for associations. Or we have to change that as well. But I think the additional value is not worth it. To be honest, I think most sites will not have multiple "dialects" of the same language installed.

The suggestion for the association tooltip looks nice. However I'd use a popover there with the language as title. I'll have a look later.

@andrepereiradasilva What would you say if we do this:

Would be the same with or without flag.

fine by me
but i would prefer the category in a new line something like

Category: xxxx

@Bakual why not using two lines?
Article (en-GB)
Category (en-GB)
and avoid also the double brackets

i would go for

language-name
------------------
article-title
Category: category-title

And i would also make that button/tooltip a layout that does not depend on the component helper ...

Good points ?

Did not we say that it should not impact frontend?
I.e. again, I would not let a Content Language without an Image.

The way this is done, it does impact when one has chosen to display flags in frontend.
Example: took off the flag for Macedonian language:

yeah, i guess the language switcher module should also check if the image exists to avoid those.

From the intial PR description:

A note: This is strictly about backend. As far as I know in frontend the only place the flags are used is the language switcher module, and that one already has a switch to toggle between flags and text.

If you don't set a flag for a specific language I'm supposing you're not showing the flags in frontend at all. I don't think anyone wants to mix it in frontend.

And i would also make that button/tooltip a layout that does not depend on the component helper ...

It already uses a JLayout, but that one isn't done optimal. It expects the link/tooltip/text already present as a string saved in $item->link. The helper class is needed anyway to query the associated items data from the database.

Updated the PR to show a popover as the association tooltip:

If you don't set a flag for a specific language I'm supposing you're not showing the flags in frontend at all. I don't think anyone wants to mix it in frontend.

we should not suppose. we should make it easier for users. this pr also forces to refactor the lang switcher as no one would understand that opting to display flags may not...

this is exactly why i think this proposal is wrong. in back-end we should have a general parameter concerning all content languages, and still assign a flag/icon to each of them.

this pr would just add confusion.

in back-end we should have a general parameter concerning all content languages

That would only be possible as a parameter in the Joomla config (ridiculous) or as a template parameter (using overrides).

this pr would just add confusion.

Why? If you set the flag to "None", no flag is shown. Quite straight forward imho. And if you set a flag to "None", no flag is shown in frontend as well.
I can adjust the language switcher module to deal with that. It's easy. I would just need to know what it should show instead. For the dropdown I'd say just show the name of the language without any flag, but what should it show in the other mode where only flags are shown? The language name or a label with SEF code? Both alternatives imho look very wrong, that's why I didn't do anything there.

i agree with bakual on this.

I can adjust the language switcher module to deal with that. It's easy. I would just need to know what it should show instead. For the dropdown I'd say just show the name of the language without any flag

Yes. Makes sense.

but what should it show in the other mode where only flags are shown? The language name or a label with SEF code? Both alternatives imho look very wrong, that's why I didn't do anything there.

I would put a label. Yes it does not look good, but remember this is just a fallback.

That would only be possible as a parameter in the Joomla config (ridiculous) or as a template parameter (using overrides).

The simple solution, as I had suggested, is a new option in com_languages.
Then that param would be fetched in the new layout.

The simple solution, as I had suggested, is a new option in com_languages.
Then that param would be fetched in the new layout.

As I said earlier, I will not do that as fetching params from another extension (com_languages) imho is a wrong thing to do. Even if it is already done today in the application, I don't think we should start doing that in every component. It just feels very wrong to me.

Architecturally, global configuration values should NOT be part of an extension of any type. These are global values and should be part of the global configuration. We should stop placing values which will affect global behavior at an extension level because it creates a bad understanding of the level of influence of the parameter (something I see in the global configuration will affect the entire site, something I see at an extension level only affects things interacting with that extension).

it would not be a global config but a com_languages option, therefore indeed at extension level.

How is it a com_languages option if it affects behavior in the entire application stack!? It is not localized to that extension only.

Ok, then let's make it an option in the back-end templates. Any Option there changes the display on the whole back-end (Colours for example). And showing icon/flags or Content Language Title Native (It should NOT be the Title) should be considered as a design choice...

You understand I still think that letting a Content Language having no image is what bothers me most.

The language switcher module now can take care of this change.
Dropdown:

Inline:

Ok, then let's make it an option in the back-end templates. Any Option there changes the display on the whole back-end (Colours for example). And showing icon/flags or Content Language Title Native (It should NOT be the Title) should be considered as a design choice...

I made that suggestion way back with my first PR and it was shot down, thus I went with this approach here...

You understand I still think that letting a Content Language having no image is what bothers me most.

No, I don't really understand what the issue is with that approach. It actually adds flexibility.

found some issues:

• a minor js issue. When you select image as "None" and save. Then edit again and try to change it again to a flag. The flag preview is not there.
• In modules menu assignments you use the langauge code, you use the SEF in all other views, so you should use the SEF here too.

As for the rest all seems to work fine.

also i think it's needed to add the same SEF fallback in recent 3.7.x merge #12042

@andrepereiradasilva Fixed the flag preview and using SEF in the module assignment. Had to add it to the MenusHelper first so I have it available in the layout.

also i think it's needed to add the same SEF fallback in recent 3.7.x merge #12042

Indeed. Should be easy to do. But changing this PR to be based on 3.7.x means I have to fix some conflicts first. I'd rather first know if it is going to be accepted or not.

I have tested this item ✅ successfully on 3127eda

Works as described.

Please don't forget to change also in 3.7.x branch and com_weblinks when/if this merged.

Rebased to 3.7.x and fixed the conflicts.

?
What a great improvement! I suggest to change the strings in mod_languages.
I am sure you will like my proposal:

@infograf768 I think we all know by now that you don't like this proposal....
Also your strings are not correct. For the dropdown it would use the flag if available. There is no "These may not be flags" as it will just be omitted if no flag is selected for that language. For the other mode it doesn't take the native name as fallback, it takes the SEF code.
If you want to change the strings (which I don't think is necessary) just append "... if available".

issue on new feature on 3.7.x branch

Thanks for the reminder. Done now:

I am sure you will like my proposal:

It was a joke, evidently. Just to show that this is not B/C.

Just to show that this is not B/C.

Sorry but that is just not true.
It is perfectly B/C as nothing changes during an update and even new installations behave exactly the same as today.
Only when the administrator actively edits the content language and removes the flag, then it will not show the flag anymore for that language. I'd say that is expected behavior and hasn't anything to do with B/C or not.

@Bakual 3.7.x as also a new modal: the menus modal
this needs to be taken care too

@andrepereiradasilva Good find. Done as well.

I have tested this item ✅ successfully on d250f24

Since that is not always an appropriate thing some expressed the wish to hide those flags...

I just can't imagine any case where a language flag is not appropriate. Can somebody enlighten me by giving an example for which this PR makes sense?

Look up what language they speak in Quebec and you have your answer

I just can't imagine any case where a language flag is not appropriate. Can somebody enlighten me by giving an example for which this PR makes sense?

I found this page quite an interesting read: http://www.flagsarenotlanguages.com/blog/
Personal example: I live in Switzerland, a country where there are four (!) official languages. You just can't use the Swiss flag to represent any of the language spoken here.

Hmm, I've always looked at the flags as 'language flags', not 'country flags'! So it has always been fine for me to use the british flag for English language content (which is used by English speaking visitors of my site, including for example Britains and Americans, and the German flag for German language content. Site admins could use Quebec's flag if they wish to target citizens of Quebec only. But I doubt that many people associate their flag with French language content.

Link: Quebec's flag

Yeah, that is what is done today. But as said, some don't want that and in some cases (like Switzerland) it just doesn't work at all. That's why this PR wants to make the flags optional in backend as well (in frontend they are already).

Ok, I understand that some German speaking Swiss citizens prefer to display 'DE' instead of the German flag ?

I have tested this item ✅ successfully on d250f24

RTC