[4.0] Flags are country flags, not language flags

[Bakual]

During the Joomla installation, there is an option to automatically create a multilingual site with the content languages already created. That is awesome.

However the logic for the language flags applied there is no proper logic at all: The issue is that there exists no language flags, they are country (or district) flags.

When a new official language is created by our translation teams, we manually have to upload a new image matching the new language code. For the german dialects this was done recently in a PR (see #11868).

Summary of Changes

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.
To be backward compatible it will first look for an existing file with the language code and fall back to the country code.

This PR also removes all unneeded files and renames some:

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

The deleted and renamed files are 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).

Known issue

The limitation here is that the languages for multilingual countries like Switzerland (in theory de-CH, fr-CH, it-CH and rm-CH) would share the same flag. The alternative is to create ugly, arbitary flags like https://github.com/joomla/joomla-cms/blob/staging/media/mod_languages/images/de_ch.gif so you get different flags for each language.
We would also have to update the images we ship to make sure the folder contains all country flags. Currently, it is a mix between flags named after a language (eg en-gif for en-GB) and country (eg us.gif or ch.gif), plus a flag for each language code (en-GB.gif and en-US.gif). So we have a lot of duplicate and inconsistently named files here (see https://github.com/joomla/joomla-cms/tree/staging/media/mod_languages/images). Already done now.

Testing Instructions

• Install Joomla and select to install some languages. Activate the option to create a multilanguage site and to create localised content.
• Check that the created content languages have proper flags for the country they are referring.

Documentation Changes Required

None that I am aware of.

[brianteeman]

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

[infograf768]

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.

[Bakual]

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.

[phproberto]

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.

[brianteeman]

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

[infograf768]

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.

[MATsxm]

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.

[brianteeman]

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

[MATsxm]

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.

[Bakual]

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).

[brianteeman]

Better yet would be not to use any flags anywhere ever

[Bakual]

Better yet would be not to use any flags anywhere ever

Not possible in J3, but maybe for J4 😄

[brianteeman]

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

[Bakual]

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)

[brianteeman]

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

[dgrammatiko]

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!

[brianteeman]

That should be an easy pr

[infograf768]

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?

[Bakual]

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.

[infograf768]

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.

[Bakual]

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.

[javigomez]

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...

[Bakual]

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).

[stellainformatica]

I totally agree with JM

[infograf768]

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

[ot2sen]

@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.

[Bakual]

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.

[MATsxm]

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...

[ot2sen]

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

[brianteeman]

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

[ghost]

As first Step change Language Switcher to

which give

and do same on Joomla-Sites:

[ghost]

One more:

[roland-d]

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

[wilsonge]

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

[brianteeman]

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

[Bakual]

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.

[HLeithner]

@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...

[Bakual]

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.

[infograf768]

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...

[brianteeman]

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

[Bakual]

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.

[brianteeman]

Afaik, populating the parameter doesn't hurt anyone.

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

[Bakual]

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.

[wilsonge]

@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

[wilsonge]

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.

[Bakual]

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.

[wilsonge]

Thankyou!

[Bakual]

See #28575