I assume your test instructions are not completely correct.

The plugin will only show if more than 1 content language is created and more than 1 language is installed.

Which all seems to be working correctly to me - thanks

Buzzwords like Progressive Disclosure are hardly new - they date back to at least 2006 https://www.nngroup.com/articles/progressive-disclosure/

The plugin will only show if more than 1 content language is created and more than 1 language is installed.

To my knowledge, the content language should be created automatically if a language is installed (but not when reinstalled). Otherwise it would be a bug in the language installer. But yes, a second content language needs to be there.

but not when reinstalled

Didnt know that

As I see it, if merged, this feature would become a hidden secret which would only be eventually used by devs and bugsquad.

It is available to every user who installs joomla in more than one language and to every user who installs joomla and then adds an additional language. It is not a hidden secret (we have plenty of real ones ). It is displayed to every user when they can use it.

It is not different to many other features of joomla which are only present if they are relevant.
For example

1. the multilingual status module
2. the language column and field

Displaying something on the control panel and then telling the user that they cant use it is a terrible user experience.

the language column and field

That one too is an issue since nothing tells users that their site can be multilingual and that they need to enable a specific plugin to do so.
When we are installing 3.x the user is informed of this possibility as soon as she/he decides to install another language, no more in 4.0.
If there was at least some information when installing Joomla that there is this possibility (and that some sample data can be installed), then this PR could make sense.

Obsfuscation is the worst user experience.

If things are hidden because currently not relevant, then there has to be an easy to use and easy to find possibility to bring it all back.

A user may decide to set up a monolingual site and then 1 or 2 years later decide to make it multilingual.

The button to show up the multilanguage status module does not need much space. So why not show this button and have the multilanguage status module enabled in any case, and enhance that module by some buttons to enable multilanguage stuff?

For example there could be a text at the top telling that the site is currently set up monolingual, if so.

Then beside the texts below there are buttons to solve the particular thing, e.g. beside "There is currently only 1 lnaguage installed" a button "Install language(s)", then beside a text "Only 1 content language is published" a button to go to the content languages view for publishing, and so on and so on, so the module could lead the user step by step through the multilingual workflow, and at the end a button for the installation of the multilanguage demo data and a text that this also includes all the previous steps.

The tool tip shown when hovering over the icon of the multilanguage status button should be advertising for the multilanguage feature, e.g. it could show on a monolingual site a different text, e.g. "Here you can make your site a multilanguage site".

Maybe there are other ways to achive the same result.

If there is such easy to find way to bring back things, then we can hide everything else on a monolingual site.

But as long as it requires people to search for diverse plugins to be enabled and settings to be done (enable associations here and there), and as long as hiding things on a monolingual site would mean to hide the existence of the great multilanguage feature of Joomla, then I agree with @infograf768 .

Except that in your scenario of converting the site a few years later ie
when there is existing content then the plugin will not work. It is not
there to convert a site to multilingual.

On Sat, 16 Jun 2018, 09:49 Richard Fath, notifications@github.com wrote:

If things are hidden because currently not relevant, then there has to be
an easy to use and easy to find possibility to bring it all back.

A user may decide to set up a monolingual site and then 1 or 2 years later
decide to make it multilingual.

The button to show up the multilanguage status module does not need much
space. So why not show this button and have the multilanguage status module
enabled in any case, and enhance that module by some buttons to enable
multilanguage stuff?

For example there could be a text at the top telling that the site is
currently set up monolingual, if so.

Then beside the texts below there are buttons to solve the particular
thing, e.g. beside "There is currently only 1 lnaguage installed" a button
"Install language(s)", then beside a text "Only 1 content language is
published" a button to go to the content languages view for publishing, and
so on and so on, so the module could lead the user step by step through the
multilingual workflow, and at the end a button for the installation of the
multilanguage demo data and a text that this also includes all the previous
steps.

The tool tip shown when hovering over the icon of the multilanguage status
button should be advertising for the multilanguage feature, e.g. it could
show on a monolingual site a different text, e.g. "Here you can make your
site a multilanguage site".

Maybe there are other ways to achive the same result.

If there is such easy to find way to bring back things, then we can hide
everything else on a monolingual site.

But as long as it requires people to search for diverse plugins to be
enabled and settings to be done (enable associations here and there), and
as long as hiding things on a monolingual site would mean to hide the
existence of the great multilanguage feature of Joomla, then I agree with
@infograf768 https://github.com/infograf768 .

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

This is what happens when you spread fud about removing a feature. People assume it is more important than it really is and that it does things that it can not do.

@brianteeman I never spoke about converting existing content.

Right, maybe the demo data plugin should not be shown there. But the other steps (install languages, publish the new content languages, publish system plugins, enable associations here and there) should be there.

Richard, none of the sample data should be displayed when the site has content. (At least in their current form) None of them will work and will die during the process with ugly red errors. Hardly a positive experience

The functionality you are talking about is nothing to do with "sample data". There are lots of ways setting up a multilingual and/it non English site Can be improved but they are off topic for this pr. For example #17019

Sure. I had the other things in mind which are hidden in case of monolingual, e.g. the language column, which was discussed above.

Regarding the plugin handled by this PR here it is off topic.

Note (unrelated to the obsfuscation issue):
Nobody said that the sampledata plugins should work when there is already some data, although it may look strange to some but I could use both the blog and multilingual sample data just by first using the multilingual sampledata and then switching admin languages before using for each langauge the blog sample data, thus adding a series of items already tagged to each Content Languages (but not yet associated).

IMHO all sample data should only be available for testing/starting play purpose and should not be delivered by core

None of them will work and will die during the process with ugly red errors. Hardly a positive experience

Umm, actually they both should work. Did you get a red error while trying so? If so what was the error?
The multilingual plugin should also be able to set up an existing site for multilingual. Sure it may change the sites home menuitems which may "break" the site, but that's easy to fix afterwards again.

IMHO all sample data should only be available for testing/starting play purpose and should not be delivered by core

No. Both the blog and multilingual plugin are fine to be delivered. The testing sampeldata was taken out to a separate repo so it can be used for testing purposes.

I wasn't able to test this....
The PR is conflicting with the latest branch.

@conconnl Yes, you can see that at the bottom of the Pull Rerquest on GitHub. Such PRs where conflicts are shown you can't test.

Exactly, only on GH.
Issue tracker doesn't show this, it suggest all is successful and you can test it.

Issue checker never shows this. It can be seen on GH only.

@Bakual Any interest in picking this up and fixing the conflicts?

I quoting from the PR description:

I'm not convinced this is actually needed, but I wrote it as promised

So no, I'm not interested in it. If someone is interested to push this, he may take the code from here and work it out.