In some cases they are not even country flags - eg arabic

This PR suggest to change the logic and assign the flags based on the country code in our language codes. Eg for de-CH (Swiss German) it would take the image ch.gif instead of de-ch.gif.

That would mean that installing de-CH and fr-CH would also use ch.gif, etc.

These images of type xx_xx.gif were created to cope with this issue.
Imagine indeed you create a multilang site which contains it-CH, fr-CH, de-CH. You would get the same flag for all these languages, thus creating a lot of confusion.
A good example with available languages is en-CA, fr-CA.
Another is es-ES, ca-ES, eu-ES
Another is hi-IN and ta-IN

As for the flags of type xx.gif, they are here to play their legacy role as, in the past, we did not have so many variations of languages.

Arabic indeed is common, as people may use the languagecode plugin to choose various country codes if they wish instead of AA which is not a country code. Then they can make their own flag/image.
Same for Swahili which uses KE for Kenya as a convenience as it is spoken in many african countries. Also for Tamil and Hindi, etc.
Esperanto has no country.

That would mean that installing de-CH and fr-CH would also use ch.gif, etc.

Exactly. Because if we threat them (rightfully) as country flags, it's the only thing that makes sense. And yes it means that you get 4 languages with the same flag. As said the alternative is to create funny flags so you can have unique flags for each language, which doesn't make sense at all.

These images of type xx_xx.gif were created to cope with this issue.

Yep, understood that. But it fails the same way country flags do.

Imagine indeed you create a multilang site which contains it-CH, fr-CH, de-CH. You would get the same flag for all these languages, thus creating a lot of confusion.

I would (and do!) use the flags of Germany, France and Italy for that. If I want to use flags. Because there is no Swiss-German or Swiss-French flag ?

A good example with available languages is en-CA, fr-CA.

Yeah, and that fails as well because you use the flag of Quebec (afaik) for fr-CA and Canada for en-CA, which is inappropriate as well.

The basic misconception here is to use country flags to represent languages to begin with. That doesn't work and shouldn't be done.
What we are doing here is a big mess in the end. We would better just include all country flags and let the user switch the image if he wants something else. If he wants to use flags at all.

For me this is a very bad idea. In Spain we have 4 different languages and believe me, seeing a common flag will get a lot of people angry. Don't try to apply universal rules based in what you consider better.

I would directly remove the flags and show the language code. Isn't that always right?

Another option is to create 2 selectors. Users pick country and then the language within that country in a differenr selector enabled after the country has been selected.

@phproberto isn't that what we have right now?

Anyway, this proposal is not B/C at all.
Because of Legacy, we have for example a ca.gif for Catalan (and its counterpart implemented when creating the multilingual installation, ca_es.gif).
If we follow this PR the Catalan flag would be used for Canada.
And anyway, we do not have a country flag for Arabic, Swahili, Tamil, Sinhala

Such a huge change, if it is desired by some, would break a lot of stuff. Please do it after my death. Thanks for your attention.

It seems that we nearly all agree that we should not use flags in a Language context then why trying to find solutions with them?
The technical point, AFAIR JM was talking about, that "would justify" using them anyway can't be fix in a way or another? (yes, once again I'm not a dev and this is over my skills).
To a non dev point of view, if some really want to use Flags for languages (agree or disagree what shouldn't be the "right" solution), this could easily be done with css or third part extensions.

Considering to use the flags, the question (with no truth as answer) will forever be, do we have to consider the location or the language name to determine the flag (considering first like @Bakual said, that we already use the correct flag what is not the case for example for fr-CA, and like @brianteeman said that the flag do exist (the one of the Arab League is the least worse solution)?

Anyway, and following @phproberto, this is a real sensitive topic for some, as for example about Catalan or Canadian as even if in the "Province of Québec" they speak French, it is not the same one (Official codification is hardly different) as the Metropolitan one neither the same as in the "Province of Nouveau-Brunswick" where Joomla! requires them to use the flag of................... Québec.

@matsxm Joomla doesn't require anyone to use any flag that they don't want
to use.

If you wanna play this game you're right Brian, we don't even need Joomla! to build a website... but the thing is the flag for fr-CA that you will find in the Joomla! lib is the one of Québec, neither the French flag, nor the Canadian one and the French spoken is Québec is not the same as in Nouveau-Brunswick.

What we could do to be perfectly B/C is that we first look if a file with the name xx-YY.gif is present, and if not we revert to the country code.
This way we at least wouldn't need to duplicate each flag (eg de.gif and de-DE.gif). Which would in fact also make the image selector easier to navigate because it has less entries. We could even remove the superfluous in new installations, we just can't remove them during updates and we would somehow have to make sure we don't overwrite possibly existing files when we add new ones. A readme file in the folder could solve that.

Also keep in mind that this are just the default flags used during installation. Each image can be changed to whatever is preferred. Of course it makes sense to have sensible default values. But as we can see in this discussion for some countries it seems to work with "regional" flags (like Spain) and for others it just doesn't work at all (eg Switzerland).

Better yet would be not to use any flags anywhere ever

Better yet would be not to use any flags anywhere ever

Not possible in J3, but maybe for J4 ?

It is possible. The only place we are forcing the use of flags right now is
to indicate the language of content in the admin. It can easily be changed
to use the language code as we are using in the associations column

True, in the admin we could remove them easily.

But we obviously can't remove them completely as they may be used in frontend by the language switcher (depending on the setting)

Yes that is an OPTIONAL setting

The only place they are forced is in the admin ui - fix that and 99% of
complaints about using flags for languages are gone

Totally agree to vanish the icons from the language indication. There are a gazillion UX article that prove coupling a language to a flag is VERY WRONG!

That should be an easy pr

This whole debate and PR make no sense.
Use the word "icon" instead of "flag" and one can flush this where it belongs.

We all should agree that an image is worth a thousands words.
These "flags/icons" are just there for convenience: they show at first sight what is what which makes the UI more readable and colorful.
No need to be an extreme nationalist to understand that.
They have the advantage of not needing a translation of the language_title.

As one of those helping a lot in the Language forums, I have seen no one complaining about these.

Anyone can indeed change the "icon" to one that fits their needs, including creating some.
If one prefers the French flag to the Quebec one, it is just a matter of editing the fr-CA Content Language.
If one is very strongly against showing the icons/flags in frontend, the parameters are there not to.

It is the role of Joomla to give that choice.

Concerning taking off the "flags/icons" in the admin — as it is so shocking for a few (remember: no one ever complained in the forums) —, it could be done as a new parameter in the Languages Manager.

We would fetch that param everywhere we use the flag/icon and display what is chosen.
But it is not sufficient to take off JHtml::_('image', 'mod_languages/' . $item->language_image . '.gif', $item->language_title, array('title' => $item->language_title), true) . ' ' . and change it to the new variable.
because in this case, we should not use anymore the Content Language title (i.e. title AS language_title) (remember: the flag may not be there anymore...) but its title_native. Therefore the queries would also need a change.

We would get something like this when the parameter is not set to flags/icons (language filter applied):

We get now

For the menus, specially the home pages, it is a bit more complex.

Is all that really worth it?

My main concern is that we ship a lot of unneeded and duplicated files.
Plus some are just plain inappropriate. Eg the Swiss German one: There should be none for that at all but we are forced to add one with the current system.

We ship quite a few files indeed (some duplicated for legacy purposes) and their weight is ridiculous compared to Joomla as a whole: 64K when zipped;
You don't like to use the Swiss German icon? just don't. ? It will be shown when you install and then you can change.

Yes, we are forced to use a new icon for each new language. Not a big deal imho.

We do indeed have more than for tiny js lang files (179k when zipped) but equal to what we will need for the new bootstrap calendar as these are based on the language tag.

We ship quite a few files indeed (some duplicated for legacy purposes) and their weight is ridiculous compared to Joomla as a whole: 64K when zipped;

It's not about size, it's about the amount. For the user it gives a huge dropdown list and for the maintainer (me in that case) it's also not optimal, especially if we could clean it up at least for new installs (no legacy purpose here).

You don't like to use the Swiss German icon? just don't.

The point is, nobody will like that. Because in Switzerland nobody uses a Swiss flag in any form to represent a language.

What would be wrong with taking the ch.gif (and dropping the de-CH.gif file) for this case and similar ones? And just creating a language specific flag where it is appropriate? I don't see the issue with that approach and it would reduce the list of images and the maintainer job quite a bit.

Just to provide context to the decision: What are other projects doing to solve this matter? I have done a quick check on known operating systems and they seem to avoid using flags, and using text instead describing language & country. In MacOS they don't even use the word "Country" but "Region" witch is more flexible. Still we can't disagree with @infograf768 that is an image is worth a thousands words, and they and are much more meaningful that language ISO codes.

If at least we can provide flexibility, then we are good. Is common that users hack some icons and flags to adapt them to their feelings. Our goal should be to have a system flexible enough to cover all the cases that we can think on. I mean allowing to optionally use flags or no, allow to language packages to adapt the way icon are selected...

So I've changed the logic now to first look if a language specific "flag" (or icon, if you want so) exists. If it does this will be used. If not, it will look for a country flag and use that one.

I also removed all unneeded files and renamed some:

• 33 files were renamed to their corresponding country code.
• 72 files were deleted because they were duplicates and are no longer needed.

The deleted and renamed files were put into a README file so we don't add files with the same name in future (and thus overwrite existing ones on user sites).

I totally agree with JM

this should never be merged in the 3.x series, period.

@Bakual Been interesting to follow this PR and discussion. Just tested the latest patch on latest staging, which seem to result in respecting b/c by using the images already available, and show those flags in the content language list.
There is a hick up with the Native title in backend for a few of them, and also in front when hovering the flags where Swiss says English for example.

Your concept of relating flags to countries is valid and correct. As Mat suggest it is important to also use correct flag in core. Should users wish to use a flag not official for the country it has to be their own choice, and they can select/enter as they always could. Easier maintenance for you and team, better quality of core provided language defaults, and b/c, then it should be an easy call.

I haven't touched anything related to the native title. You're sure that behaviour is new with this PR? That's strange.

this should never be merged in the 3.x series, period.

@infograf768 With all respect, but why? It's completely B/C and respects the concerns you raised.
Basically it is now a clean up of the files, making them consistent and reducing the amount. But all is done only for new installs. Nothing will change for an update. I don't understand why you block that hard now.

Still we can't disagree with @infograf768 that is an image is worth a thousands words

Sorry, but I totally disagree on this urban legend of the past.
Just check the internet today and you will see so many articles from UX and l10n specialists saying it is NOT a proper way to define a language with a flag (or icon what ever you want to call it...).

And even if, this does not justify the use of wrong flags, nor to create hybrids that make no sense.
But this, I confess, is another topic.

https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=use%20flag%20language and so many others...

@Bakual You´re right. Those native titles issues are not related to this PR, also happens without the patch.

While looking up the flag we use for Swahili I stumbled over this interesting site: http://flagsarenotlanguages.com/blog/category/swahili-kiswahili/
It also tells a bit about the topic of "an image is worth a thousands words".

@ot2sen and @Bakual

I haven't touched anything related to the native title. You're sure that behaviour is new with this PR? That's strange.

It is not strange. It is a bug. These languages do not have an installation ini file. I already explained why (same reason as nl-BE, as browsers do not differentiate these).
This is solved in this PR: #11867 for 3.7.0

For staging/3.6.3 I did propose a fix:
#11867 (comment)

Again, @dgt41 & @MATsxm
The flags/icons do NOT have to be used in frontend. Users should have the choice, whatever "specialists" say.
Joomla should let the choice.
How many times should this be repeated?

As for the backend, this PR forces the use of the same icons/flags for some languages with no way anymore to differentiate, confusing users.
Taking off useful icons allowing to differentiate the languages used is not the solution.
this PR is so systematic that it proves wrong:
br-FR is Breton language: You take it off. We may not have a Breton pack now ( I have seen some incomplete ones used on the net though) but the icon is also used by sites using a copy of fr-FR. If these sites use also fr-FR, and even if they don't, they certainly do not want to use the fr.gif flag.
Sinhala would now have the Sri Lanka flag, but Tamil is the second official language of Sri Lanka and righfully gets the general icon
No way either to differentiate between language variations in Switzerland, not speaking about India.

I wonder if I should continue posting here as I have the feeling it is useless.

You mean the native title is taken from the installation languages files instead from the language package? That sounds completely wrong to me. It should be defined in the language package itself.

It has been like this since was implemented the multilingual installation at Joomla install time.

; IMPORTANT NOTE FOR TRANSLATORS: Do not literally translate this line, instead add the localised name of the language. For example Spanish will be Español
INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME="English (UK)"

btw, @andrepereiradasilva proposed to add the native language in the various xml(s) as a new metadata.

All this is obviously not for 3.6.3...

As for the backend, this PR forces the use of the same icons/flags for some languages with no way anymore to differentiate, confusing users.

Wrong. It doesn't change any flag at all. It uses the exact same flags it would use today. Just using different names for the flags (country code) and reducing the duplicates. Where there is an additional language in a country (eg ca-ES) its "flag" is added named as the language code.
As I wrote I have listened to you and adjusted the code to make exactly this possible. That's why I don't understand you still refusing it completely.

br-FR is Breton language: You take it off.

That is true. I removed those flags because I didn't found out what the language code should be and didn't recognize the flag at all and there also is no language pack for it. So I thought it's one of those legacy flags nobody uses. But if that is wrong there is no problem adding the br_fr.gif again (br.gif still can be deleted).

Sinhala would now have the Sri Lanka flag,

Actually it uses the same flag as before. I wrongly assumed it is the Sri Lanka flag but it isn't. I can change that back. Tamil still gets the tm-IN.gif as it got before, I just removed the tm.gif which wasn't used before.

It has been like this since was implemented the multilingual installation at Joomla install time.

And it can't be changed for what reason? Why can't we add the same to the language packs? Especially since with that other PR we will use it in production sites where the installation folder is deleted, and especially sinc we actually have already issues present with that approach.

All this is obviously not for 3.6.3...

3.7.0 is close and there it can be added without issues.

And it can't be changed for what reason?

Did I say it can't be changed? It just should not for 3.6.3. The new code would just have to make sure that the new metadata exists (in the site xml imho) and fall back to the metadata name if not.

In the meanwhile, I can create a PR with the code I proposed for 3.6.3. But I would not change the flags thing.

It is completely unrelated to the flags anyway.

Added back the wrongly deleted files and added a proper Sri Lanka flag (will currently not be used by default).

Except for the Swiss flag being used by default for de-CH, I am OK with this solution.

Except for the Swiss flag being used by default for de-CH, I am OK with this solution.

Trust me, there is no proper flag to be used for de-CH. Everything else will be a joke or even offensive to Swiss people.

If we add a fr-CH or an it-CH pack, what would we use? The Swiss flag too?

If we add a fr-CH or an it-CH pack, what would we use? The Swiss flag too?

Yes, because there is no other choice. That is why almost nobody in Switzerland uses flags to indicate the language. See for example https://www.admin.ch, http://www.myswitzerland.com, http://www.sbb.ch, http://www.20min.ch, https://www.ubs.com, https://www.galaxus.ch to name some.
Those few who use flags (haven't found one right now), use the Germany, France and Italy one, but we can't use those in Joomla as well since we would face the exact same issue. So just use the CH flag and let the user change it if he wants to.

no need to say that IMHO, there's no perfect solution BUT @Bakual 's one is far the best one and the modern logic we need and used nearly everywhere... even in Canada...

@bakual and others - what is the status of this?

The user can now remove the language flag if he wants to. So the flags are not mandatory now.
There is a bug remaining #12907 that needs to be solved.

reggarding if this PR still makes sense or not, no idea.

Thats what i was thinking. Not sure this PR is needed now

It's not needed, but it will make our lives easier in the future as we don't have to create a flag for each language pack we add. We just make sure we have a flag for the country.
For 4.0, we can clean up even more and rename the currently incorrectly named flags (like the belgian one). Due to B/C this isn't possible with this PR.

Maybe it makes sense to do this 100% in the J4 tree and then we dont have to worry about breaking b/c

Yep, probably makes more sense at this time. I'll do it when I find some free time ?

Rebased this PR on 4.0 and changed the base branch. Actually there were no conflicts between the branches.

Since we now could break backward compatibility, the question is if we want to clean it up further. Eg the flag for belgium is named belg.gif and nl_be.gif, but it should be be.gif. However be.gif is currently present for the "Belarusian" language (https://github.com/joomla/joomla-cms/blob/staging/media/mod_languages/images/be.gif). So if that image is currently used for Belarusian on a site, J4 would change that image and show the Belgium flag instead. They will have to change it to by.gif manually.

If that is fine, I can make the needed changes.

@Bakual if you're doing this against 4 then you should consider dropping the gifs for svgs.
You can pull the images from https://github.com/lipis/flag-icon-css
You can edit the Gruntfile.js to do this automatically (easy updates)

@dgt41 ? ? ?
WHOOTWHOOT, even a flag for SXM!

Honestly, that is far beyond what I intended to do with this PR. It would be a completely other approach. However it could work out very well as there is no B/C break involved.
It also would make sense to move the flags to the vendor because they are not only used in mod_languages but all over the places currently.

HOWEVER

• We would have to think of a way to allow language specific "flags". Adding own files to that vendor directly is obviously not a good idea.
• Overrides have to be possible. I'm not sure if they work for svgs currently, maybe that works already.
• That project contains a lot of flags which we probably never need due to missing language packs, which makes the list for the user double the length of today. While the idea of this PR was to make the list smaller. To give some numbers:

• currently: 162 files,
• this PR: 93 files (could likely be reduced even further)
• library: 255 files (plus possible language specific)

@Bakual you don't have to deliver the exact copy of their repo, we are doing the same with many other external libraries. The script can be adjusted to copy only the ones required (although I think all 180+ known countries should exist in Joomla)

(although I think all 180+ known countries should exist in Joomla)

That still would give a list of ~180 items then, compared to the ~90 I would have done. It's gonna be a huge list anyway, it wouldn't matter at all if it is 180 or 255 at that point. ?
On the other hand, 90 is still a huge list as well so it may not matter much. At least the file name would be predictable.

yeah, and also we divert the actual workload elsewhere. win-win!

How do we solve the language specific "flags" (eg "ca-es")?

Rebased this PR

Where do we stay here?

Needs some decision:

• Do we want to go this way.
• If we do, do we want to go even further and rename existing, inappropriately named files:

Since we now could break backward compatibility, the question is if we want to clean it up further. Eg the flag for belgium is named belg.gif and nl_be.gif, but it should be be.gif. However be.gif is currently present for the "Belarusian" language (https://github.com/joomla/joomla-cms/blob/staging/media/mod_languages/images/be.gif). So if that image is currently used for Belarusian on a site, J4 would change that image and show the Belgium flag instead. They will have to change it to by.gif manually.
If that is fine, I can make the needed changes.

• Do we want to drop the gifs and use SVGs? Then we also need a solution for language specific "flags" and some other things. See #12014 (comment)

as long as we have images for languages then we cant move on

As first Step change Language Switcher to

which give

and do same on Joomla-Sites:

One more:

@wilsonge Can you make a decision here if this should be continued or not?

@marcodings @HLeithner can you give feedback here please as you build more multilang sites than i do

This PR suggest to change the logic and assign the flags based on the country code in our language codes

That doesnt work as explained by several nationalities

The easiest way to stop repeating the fake connection between an image and a language is to stop setting a flag at all. The field (and standard flags) can still be included in joomla so a user can chose one of those if they want but we simply stop using these incorrect and/or fake flags by default

The easiest way to stop repeating the fake connection between an image and a language is to stop setting a flag at all. The field (and standard flags) can still be included in joomla so a user can chose one of those if they want but we simply stop using these incorrect and/or fake flags by default

If you ship them, you need a way to assign them to a language. Otherwise it's useless to ship them as they can't be used without modification of the code.

Anyway this PR doesn't try to solve this issue. All it does is that it reduces the amount of flags due to duplicates. And it names them correctly to the country code instead of a language code.

@marcodings @HLeithner can you give feedback here please as you build more multilang sites than i do

I'm in favor for it, I normally create German language sites with an Austrian flag and have a English Version with the British flag. I would also like to see svg files instead of the gif files (even if they might be bigger the scale).

But iirc it's not possible to select the Austrian "language" with the german language pack as fallback (but this was sometime ago don't know if this have changed). Also my last try to use /de-de/ and /de-at/ as urls didn't worked that was also a long time ago.

So basically it's wrong to use country flags as language symbol but we don't have any other symbol so it's ok for me and many people on the web...

But iirc it's not possible to select the Austrian "language" with the german language pack as fallback

You can. In the content language you can select whatever flag you want.
But we don't need both a de_at.gif and a at.gif for this, the latter would be enough.

Let me repeat here again:

1. I'm in favour (for J4) of simplifying the # of icons by keeping only the images corresponding to the lang tag, i.e. fr_fr.gif and kill fr.gif to allow separating icons by language and let these be set when installing a language. It is simple and it works fine.

2. As we can easily decide to NOT USE AN ICON if preferred (by not selecting an image in the Content Language field), the possibility of using icons should be left to the user decision.

In admin, user is now getting :

Icon Selected

No icon selected

The possibility using or not icons is present in mod_languages and has been for ages...

As we can easily decide to NOT USE AN ICON if preferred (by not selecting an image in the Content Language field), the possibility of using icons should be left to the user decision.

I agree with you. Let the user ADD an icon if they want to

I'm in favour (for J4) of simplifying the # of icons by keeping only the images corresponding to the lang tag, i.e. fr_fr.gif and kill fr.gif

This PR goes the other way around and kills the fr-fr.gif and keeps the fr.gif. But it still allows to use eg a fr-ca.gif. The lookup order is first "xx-xx.gif" and second "xx.gif. Thus it's fully backward compatible and still reduce the amount of icons while naming them appropriately (as country flag).

Let the user ADD an icon if they want to

As long as we have that parameter in the content language and we also ship the flag icons, it doesn't make sense to NOT populate the parameter and force the user to ADD it.
Afaik, populating the parameter doesn't hurt anyone. If they show somewhere by default, it would be dead simple to change that default parameter.

Afaik, populating the parameter doesn't hurt anyone.

It just perpetuates the bad practice of associating a language with a country

It just perpetuates the bad practice of associating a language with a country

Then do an own PR to remove the flags and the parameters in the language switcher and content language. As those are the real source of the bad practice.
This PR doesn't want to change anything there. It just tries to reduce the amount of flag files we ship by changing the logic a bit.

Honestly I'm surprised how much discussion and time (over 3 years now!) that requires to do such a simple change.

@Bakual fix conflicts. Talked with @rdeutz and he also agrees with this PR (as well as @HLeithner ). So I'll get this merged.

Having said that in a future PR (not this one) if we could find SVG icons instead of these GIFs that would also be excellent for looking forward

If people want to change the default settings on whether to use flags or not I'd also be open to a Pull Request where that discussion can play out.

I tried to do a a merge but it's to many conflicts since some icons got changed and the whole thing moved to a different place.
Also the PHP function doesn't exist anymore in the installer, so I need to adjust it anyway

So I will redo the PR in a new one and reference it.

Thankyou!

See #28575