Do the new icons really make any sense given the full lang code text is already displayed. I'd just be simple and remove them all together......

Do the new icons really make any sense given the full lang code text is already displayed.

thats only displayed in the screenshot because its in the title of the menu - doesnt have to be ;)

In my opinion this should be centralized in com_languages, ie, for great flexibility give the user the option to choose if he wants a image (ex: flag) or not to represent each content language.

I start going that way some time ago, but didn't have time to continue.
See https://github.com/andrepereiradasilva/joomla-cms/pull/78/files

If anyone want to take that code and continue the work for me it's fine.

I agree with @andrepereiradasilva
This PR works but its really hidden there and we will end up with lots of places that a user has to change the setting to use flags or not.

In my opinion this should be centralized in com_languages

I thought about that, but I think it is the wrong place. Simply because we would have to read the parameters from com_languages in each extension.
Imho it either has to be in the global configuration (not that great idea) or in the template parameters (it's a design question in the end).
Having had a look now at the approach from @andrepereiradasilva and I like the idea of using a JLayout. Using that, we could use an override in Isis which uses a template parameter to change the flags.
That would work fine for all lists (if the extensions are updated to use the JLayout).

However it would still not work for the menu module and it would not work for the associations tooltips.
For the menu module, I thought this PR would be fine and for the associations we can imho just remove the flags in the tooltip. They make no sense anyway since we already know the language because we hover over the language sef code.

So that would account for two parameters in the end. One in the template and one in the menu module.
Or we could do an override for the menu module layout, but I'm not that much in favor of this.

I thought about that, but I think it is the wrong place. Simply because we would have to read the parameters from com_languages in each extension.

No, see my PR, the option to not select flag is in the content language itself.

Imho it either has to be in the global configuration (not that great idea) or in the template parameters (it's a design question in the end).

Don't agree, IMHO should be a choice of the user not depending on the template. That's why i put the option in the content language itself Image: None.

Having had a look now at the approach from @andrepereiradasilva and I like the idea of using a > JLayout. Using that, we could use an override in Isis which uses a template parameter to change the flags.

Yes, that was the idea and also avoid duplicated code.

However it would still not work for the menu module and it would not work for the associations tooltips.
For the menu module, I thought this PR would be fine and for the associations we can imho just remove the flags in the tooltip. They make no sense anyway since we already know the language because we hover over the language sef code.

That's why i have different code in those in the PR. And there's also the template styles that can be assigned to a content language (i didn't add time to touch that in my PR).

So that would account for two parameters in the end. One in the template and one in the menu module.
Or we could do an override for the menu module layout, but I'm not that much in favor of this.

In my approach you don't have parameters at all, the user just select if that content language as image (ex: flag) representing it or not, ie, doesn't force the user to select an image.

Don't agree, IMHO should be a choice of the user not depending on the template. That's why i put the option in the content language itself Image: None.

Ah I missed that. However that would mean you can't remove the flags in the backend and have them in the frontend. However I'm not sure if that is a use case at all.
It would of course create an invalid image for extensions that aren't updated, but I guess that's not a big issue.

I was more thinking that users likely want to show all flags or none. Not that they want to show flags for particular languages and no flag for others. Thus I didn't even think about adding that possibility in the content language itself.

Another approach I was thinking about was to simply add a class flag to the images and then use
img.flag {
display: none;
}
in Isis when the parameter is set accordingly.

My original proposal was to have a global parameter in com_languages General Options: Flags or not. Then fetch that param where necessary. For administrator only.

Yeah, that would be an architectural disaster if we're going to fetch a param from com_languages in every extension. That's why I would prefer another approach.

IMHO the most logic approach is allowing selecting no image in each content language

The field i already there, the database field is already there is a matter of allowing empty values in that field and making the necessary changes to not display the image in those cases.

Example, if you don't what image just edit the content language and select no image.

Choosing by content language does not make sense imho.
What would you replace it with as it has to be replaced by "something"?
What would it be in frontend if someone likes the flags?
A UI should be consequent: or all have, or none.
And in admin only, as the choice already exists in frontend.

What would you replace it with as it has to be replaced by "something"?

Not necessary. Where the language name is written already, there doesn't need to be anything else.

What would it be in frontend if someone likes the flags?

That is what I wonder personally. Does someone who likes the flags in frontend really want to remove them in backend? I'm currently thinking they probably want it the same in front- and backend anyway.

Not necessary. Where the language name is written already, there doesn't need to be anything else.

The language full name (Remember, it should be the native name to be understood clearly —as no more icon) would not fit everywhere in the UI.

We just can't get rid of the flags for each Content Language anyway as indeed they are needed in frontend for those that want them.

In admin, the flag could possibly be replaced by the sef button/icon if the general parameter is set for ALL content languages, i.e. a general parameter. That is the only sensible thing I can think of.
Default to flags as, after all, it is only a handful of people who are suddenly shocked by these icons in back-end...

Default to flags as, after all, it is only a handful of people who are
suddenly shocked by these icons in back-end...

No it is not. It is just that you have always been much more successful in
silencing them

On 15 September 2016 at 12:24, infograf768 notifications@github.com wrote:

Not necessary. Where the language name is written already, there doesn't
need to be anything else.

The language full name (Remember, it should be the native name to be
understood clearly —as no more icon) would not fit everywhere in the UI.

We just can't get rid of the flags for each Content Language anyway as
indeed they are needed in frontend for those that want them.
In admin, the flag could possibly be replaced by the sef button/icon if
the general parameter is set for ALL content languages, i.e. a general
parameter. That is the only sensible thing I can think of.
Default to flags as, after all, it is only a handful of people who are
suddenly shocked by these icons in back-end...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12034 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8dxcA0CpDBvkYZTivlDyQpooXnmIks5qqSrrgaJpZM4J8pJr
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

The language full name (Remember, it should be the native name to be understood clearly —as no more icon) would not fit everywhere in the UI.

I referred to the lists:

When there is no flag, it wouldn't be an issue at all. You can even remove it for the tooltip as the language information is still there (mouse actually hovers on it).
For the other places like in the menu module (this PR) it could fall back to the SEF code and it would look like proposed here.

my goal was to avoid an extra parameter that you already have a field for it.
It doesn't seem an issue to me if a user don't want flags in the backend 20 seconds or less setting the content language images to "None".

Yeah, that would be an architectural disaster if we're going to fetch a param from com_languages in every extension.

We're already doing that at the application level. The app classes have hardcoded dependencies to com_languages AND com_users parameters. Kinda surprised we're now worried about architectural coupling between extensions considering we've already got a major mess on our hands in other ways.

We're already doing that at the application level. The app classes have hardcoded dependencies to com_languages AND com_users parameters. Kinda surprised we're now worried about architectural coupling between extensions considering we've already got a major mess on our hands in other ways.

Yeah i notice that in my performance tests also ... https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/application/site.php#L586-L607 and https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/application/site.php#L660

Let's try to not repeat past mistakes ... ?

Let's try to not repeat past mistakes

Wasn't aware but what Andre said ?

Based on the discussion here and the work from @andrepereiradasilva, see #12051 if that would be a better solution.

@Bakual should we close this and go to #12051 ?

Yeah, I'm closing this. The other one is probably the better approach and having both make no sense at all ?

Thank you