To my understanding you do not need content languages on monolingual sites.
Now to my surprise en-GB turns up in the language selection lists even if I unpublish it as content language. Shouldn't language All be the one and only?

I still e.g. can choose to work (log in) in an English backend, even if the used content language is another one. As in all systems, the documentation is better and easier to find in english or another "major" language.

i.e. as I understand, you only have to go through the "complicated step" on multilingual sites where you also need a couple of other steps with plug in and module. Not to mention the duplication of all menus.

No reason, except that it is not necessary on a monolanguage site where even en-GB content language is useless.

On a monolanguage site installing languages is only used to change the strings to the language preferred by the user for the UI. The Language field is unnecessary there, and, a fortiori, content languages.
Then why do we show that field on monolanguage sites? For a simple reason: B/C. Some people have used that field for other reasons than multilingual. We had an example where it was used to differentiate schools.

@schnuti it is because it exists by default in English that I now ask this question ;)

@infograf768 yes it isnt necessary but it also doesnt create a problem (does it?) as can be see by the fact that you always have an english content language

imho, it is just confusing users to always have an en-GB content language displaying in the field when the site is monolanguage.
Indeed, it does not create any issue code wise.

(I kind of remember the en-GB content language was created in sample data because Elin wanted to show some example.

@brianteeman @infograf768 From a UX perspective that field shouldn't be revealed for monolingual sites

I agree it shouldn't be displayed on a monolingual site.

That's not the question.

I am asking if there is a reason we don't create the content language
automatically. It's a complex form that many people struggle with. Choosing
to display it or not is a different issue

Unpublished content languages should not appear in language selection lists for content. If this is solved other installed languages could be added to content languages - but unpublished.
I tested this. Unpublished content languages appear in the list. i.e. this list can be long and confusing on a monolingual site if administrators prefer different languages.

Isn't that a bug?

yeas sounds like a bug to me

On 1 August 2016 at 10:15, Ove Eriksson notifications@github.com wrote:

Unpublished content languages should not appear in language selection
lists for content. If this is solved other installed languages could be
added to content languages - but unpublished.
I tested this. Unpublished content languages appear in the list. i.e. this
list can be long and confusing on a monolingual site if administrators
prefer different languages.

Isn't that a bug?

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/11376
https://issues.joomla.org/tracker/joomla-cms/11376.

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

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

Unpublished content languages should appear in the language field.
This was specially designed for users to be able to prepare a new language in multilang without yet showing it on site. The functionality was coded by Andrew Eddie.

@infograf768 that should be conditional, I mean you will only spent a fraction of the sites lifetime preparing new language content, the rest of the time you either have the language enabled or disabled for whatever reasons

About monolingual sites , ok, the content languages should not be created automatically

Maybe this title is better ?:
"Make creation of content languages easier"

• User installs some language pack, and then user thinks that the content language have been created, but they are not there, that is a little strange / yet uknown step for non-experienced users

I don't say to create content language automatically,

• but make it 1 click process, and at the installed languages list, displaying a new column , "Content language" and a button "Create" in each row, with a tooltip, "Create content language so that you can use it in your content" (or something better) ?

• The same change had been made for menus to create a corresponding menu module

the difference here, would be that either we do not display the new content language form at all, or we display it with -all- / most fields auto-populated ?

Just because something was written 10 years ago doesnt mean it is still
what we want to have today

On 1 August 2016 at 10:50, Georgios Papadakis notifications@github.com
wrote:

About monolingual sites , ok, the languages should not be created
automatically

Maybe this title is better ?:
"Make creation of content languages easier"

• User installs some language pack, and then user thinks that the content language have been created, but they are not there, that is a little strange / yet uknown step for non-experienced users

I don't say to create content language automatically,

-

but make it 1 click process, and at the installed languages list,
displaying a new column , "Content language" and a button "Create"
in each row, with a tooltip, "Create content language so that you can use
it in your content" (or something better) ?
-

The same change had been made for menus to create a corresponding menu
module

the difference here, would be that either we do not display the new
content language form at all, or we display it with -all- / most fields
auto-populated ?

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

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

Things like this make Joomla feel a little more complex to setup

I see considerable work happening here:
https://github.com/joomla-projects/gsoc16_improved-multi-lingual

maybe this is worth considering doing, i am sorry that myself, i can not spend any time now

IMHO unpublished Content languages have to appear in the language selector field.

Imagine you unpublish a language.

All the contents (articles, menus, categories, modules, etc) with that language are still in that language.
So when you edit one of that contents you need the correct value for the language field there.

I use this several times when creating a new language with the site online.

IMHO, from a UX point we could also improve that selector to make unpublished languages greyed out or something.

But i also don't see any issue here. We can just create the content language unpublished on install and i don't see any issues with that content language appearing in the language selector field.

I see considerable work happening here:
https://github.com/joomla-projects/gsoc16_improved-multi-lingual

That project as nothing to do with this issue.
See http://magazine.joomla.org/issues/issue-june-2016/item/3054-gsoc16-improved-multi-lang for more info

@andrepereiradasilva

I use this several times when creating a new language with the site online.

Can you always have the languagefilter plugin active in this phase of the site creation?
I added a check if the language filter plugin is active to the ContentLanguage field type. i.e all content languages are listed if plug in is active else only "All". That is what I expected.

Any B/C issues? Otherwise I would say that the languages could be added as unpublished content languages at installation. A monolingual site (the very most) do not have to see any extra buttons and tooltips.

Can you always have the languagefilter plugin active in this phase of the site creation?

I think so, don't recall.

I added a check if the language filter plugin is active to the ContentLanguage field type. i.e all content languages are listed if plug in is active else only "All". That is what I expected.

What if you are editing a item that is already set to a unpublished language?

The unpublished languages are handled as before. Maybe they should be marked in some way as you said.
The change is only that NO content languages are shown on monolingual sites. (deactivated plugin) As default is now en-GB shown in those lists on ALL sites. i.e. en-GB but NOT your installed language (e.g. de-DE or pt-BR ...)

The change is only that NO content languages are shown on monolingual sites.

You mean change the content language form field to be an disabled/hidden field with the default/original value if language filter is desactivated.
I can be missing something, but, If anyone does a PR, i don't see a problem with that.

But would that solve the issue we are talking about here (Automatically create content languages?)?

@brianteeman
I think your idea fails if unpublished content languages have to be included in the select lists.
see @infograf768 and @andrepereiradasilva

Following example is exotic but not impossible.
A site targeting a border area involving 3 content languages. e.g. Polish, German and Czech. The site administrators prefer to work in English and French in backend. The selection lists used by the authors will then include 6 languages (including All) from the start till the end of days. No one will accept that, so instead of manually creating the 3 content languages, 2 have to be deleted from the list of content languages. Not exactly a win - win situation and as confusing.

Get rid of the annoying English on single language sites is easier resolved by setting the status to trashed. I would not delete it. It could become reactivated by a future update for some reason.

@andrepereiradasilva

But would that solve the issue we are talking about here

No, but it's a prerequisite. Or do you want a list of content languages on single language sites? Compare example above for multilingual site.

I'm in @schnuti : I use English interface for myself (power user) but localized for other regular users.
Perhaps during language installation there could be a pre-checked checkbox 'Add content language'.

that sounds like a good compromise

On 3 August 2016 at 21:32, Piotr notifications@github.com wrote:

I'm in @schnuti https://github.com/schnuti : I use English interface
for myself (power user) but localized for other regular users.
Perhaps during language installation there could be a pre-checked checkbox
'Add content language'.

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

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

Something like this perhaps

Good idea!
I would keep the checkbox unchecked.
1. The very most installations do not need any content languages (90% ?), only the translated text strings.
2. If it gets forgotten at installation the "reinstallation" is easier then explaining to a user, not at all interested in multilingual, how to delete the created entry.
3. This also implies that all languages are listed in the selection list. Installed not excluded but marked in some way.

The en-GB entry should be removed as default entry as content language. It should be included in the selection list as any other installed language.

See #11867

Closed