@infograf768 What do you think?

will test tomorrow. i have to test what happens when one switches languages in admin and installs again the blog sample data. my first thought is that the names of items should be amended with (xx-XX). Also that the description of the sample data displayed in the module should explain this feature when in multilang.

If the sample data is not translated and thus has the same name, then it will refuse to install due to duplicate alias.
We could add code to add the language tag to the alias indeed. That would work around this potential issue.

This is what I have done. It works fine. I installed blog sample data in both en-GB and when fr-FR is admin language. There is not yet any fr-FR ini for the blog, thus why the titles and contents are still in English. Here for categories.

I still need to solve some issues

BTW, I added this code where it should be:
$lang_suffix = Multilanguage::isEnabled() ? ' (' . strtolower(JFactory::getLanguage()->getTag()) . ')' : '';

and for example

$categoryTitle = JText::_('PLG_SAMPLEDATA_BLOG_SAMPLEDATA_CONTENT_CATEGORY_0_TITLE') . $lang_suffix;

The issues I have to solve concerns the catid for the blog menu item (I always get index.php?option=com_content&view=category&layout=blog&id=9 and the homes when they are already set when installing the site as multilang (need to keep the default Homes already created)

Solved the last issues.
Now the blog uses as id the specific catid and not a hardcoded one (this was imho also a bug in monolingual)
And, in multilingual, if it exists, it keeps the language Home menu item that was created when installing Joomla or later on.

blog.php.zip

@Bakual Please download the zip and test.

JM's proposal work for me

@infograf768 Few questions:

• Is there a reason you force the tag to lowercase? Imho we can just leave it at eg fr-FR, or not?
  I think we can also move it to the code where the content is actually pushed to the model, so we don't have to add the suffix to each item individually.

• If we don't change the home menuitem for multilingual, we can also just remove it from monolingual as well. It's something that isn't necessary to be present in the sample data. We could decide to just remove the home menuitem creation/handling from the plugin and leave the current home menuitems as is.

• The category thing indeed was a bug. Thanks for detecting and fixing!

@Bakual
lowercase: I just did as we do when we install J as multilingual , keeping the tag as is is ok.
If you find a way to simplify the code, I am all for it.

home: the idea was that one could install a new language, switch to that language in admin and then also install this sample data. The home for this new language (which has nothing yet in db) would be taken care of by the plugin.

i did not try in my proposal to also publish the new content language in that case.
it should be possible.

Concernng home, just remarked my code does not set the new language Blog Home page menu item to home. I may have an error in my code.

// Keep a multilingual "Home" menu item if it already exists
		else
		{
			if ($menuItemTable->load(
				array(
					'home'     => 1,
					'language' => $language,
				) != null))
			{	
				$home = 0;
			}
			else
			{
				$home = 1;
			}
		}

That part should be

// Keep a multilingual "Home" menu item if it already exists
		else
		{
			if ($menuItemTable->load(
				array(
					'home'     => 1,
					'language' => $language,
				)))
			{	
				$home = 0;
			}
			else
			{
				$home = 1;
			}
		}

?

@Bakual
To publish the content language for a newly installed language, where could we put this code (or similar)?

		if (Multilanguage::isEnabled()
		{
			$db = JFactory::getDbo();
			$db->setQuery(
				$db->getQuery(true)
					->update('#__languages')
					->set('published = 1')
					->where($db->quoteName('lang_code') . ' = ' . $db->quote($language))
			)->execute();
		}

I added it to step2 to check if it was working, and it does.

@Bakual
Ok, solved it by adding a new step which publishes the Content Language

blog.php.zip

I now get correctly (strings not added yet)

Needs some iron out (strings, methods comments), but other wise we should be good.

Just to be clear, the purpose of this PR isn't to set up a multilingual site. It just should install the data with the correct language.
If home or the content language is missing for the active language, then it should not magically fix that.

We can add code to set up a multilingual site, but it should be an own plugin, not the blog one. In that plugin we could then also take care of association and everything.

I guess my proposal is now fine and will provide blog sample data when the site is multilingual and the sample is installed for any existing language by just switching admin language.
No assoc but making sure we have a home (existing already or not) for any language, even those installed later on. Also making sure the Content language is published.
I guess this is the minimum we can expect from such a sample data plugin.

When the site is multilingual, it should show on frontend, which it now does correctly.

Added some improvements and bugfixes suggested by @infograf768

• I removed the "home" handling. I think it's actually better if we don't mess with the home menuitem anyway. Less risk for the user ?
• I didn't add the content language handling JM suggested. Imho, we should just add the content and not try to fix the multilingual site setup. Maybe we should instead add a check if the content language is active and if not apply the language "All" (*) to the items. This would be possible but makes the code more complex and imho doesn't have much value.

Frustrating that homes are not set as can be easily done with my patch.
In any case, some strings have to be modified.

PLG_SAMPLEDATA_BLOG_SAMPLEDATA_MENUS_ITEM_0_TITLE="Blog Home"

As this is not a Home anymore, I guess "Blog" would be enough.
PLG_SAMPLEDATA_BLOG_SAMPLEDATA_MENUS_ITEM_0_TITLE="Blog"

Also
PLG_SAMPLEDATA_BLOG_OVERVIEW_DESC="Sample data which will set up a blog site."

should be modified to explain what happens when using this blog sample data on a multilingual site.

Frustrating that homes are not set as can be easily done with my patch.

Imho, we should rather add an own sample data plugin which will completely set up a site as a multilingual site. Better than shoving such logic into a pluzgin which has a different purpose.

should be modified to explain what happens when using this blog sample data on a multilingual site.

All it does is creating the content with the active language. Does this really need to be written in the description? I have a feeling we end up with a wall of text then.

or simply use isMultilang to remove the option to install the sample data on a multilingual site

PLEASE no walls of text

or simply use isMultilang to remove the option to install the sample data on a multilingual site

In that case, this PR is totally useless... and we should just prevent the module from displaying this plugin as it is not multilang aware.

Let's say we keep it, not informing the NEWBIE (a trained user would never need to install sample data) that, in multilang, one has to switch language in admin and install the sample data for each of the installed languages, makes it a very much hidden feature.

Enough fighting against windmills for me.

Too much opposition here. If no explanation to the user, let's not indeed make blog and testing installable on a multilingual site. (some bugs also corrected here)
Code proposed:

diff --git a/administrator/modules/mod_sampledata/helper.php b/administrator/modules/mod_sampledata/helper.php
index a266856..d59cec5 100644
--- a/administrator/modules/mod_sampledata/helper.php
+++ b/administrator/modules/mod_sampledata/helper.php
@@ -10,4 +10,6 @@
 defined('_JEXEC') or die;
 
+use Joomla\CMS\Language\Multilanguage;
+
 /**
  * Helper for mod_sampledata
@@ -30,4 +32,13 @@
 		$data = $dispatcher->trigger('onSampledataGetOverview', array('test', 'foo'));
 
+		// Do not display the sample data when it is not specifically optimized for a multilingual site
+		foreach ($data as $sample => $sampledata)
+		{
+			if (Multilanguage::isEnabled() && $sampledata->multilang == 0)
+			{
+				unset($data[$sample]);
+			}
+		}
+
 		return $data;
 	}
diff --git a/plugins/sampledata/blog/blog.php b/plugins/sampledata/blog/blog.php
index b294605..b744327 100644
--- a/plugins/sampledata/blog/blog.php
+++ b/plugins/sampledata/blog/blog.php
@@ -69,4 +69,7 @@
 		$data->steps       = 3;
 
+		// This sample data is not optimized for a multilingual site
+		$data->multilang   = 0;
+
 		return $data;
 	}
@@ -334,5 +337,5 @@
 		$menuItemTable->load(
 			array(
-				'home' => 1,
+				'home'     => 1,
 				'language' => '*',
 			)
@@ -341,4 +344,7 @@
 		$menuItemTable->store();
 
+		// Get previously entered categories ids
+		$catids = $this->app->getUserState('sampledata.blog.articles.catids');
+
 		// Insert menuitems level 1.
 		$menuItems = array(
@@ -346,5 +352,5 @@
 				'menutype'     => $menuTypes[0],
 				'title'        => JText::_('PLG_SAMPLEDATA_BLOG_SAMPLEDATA_MENUS_ITEM_0_TITLE'),
-				'link'         => 'index.php?option=com_content&view=category&layout=blog&id=9',
+				'link'         => 'index.php?option=com_content&view=category&layout=blog&id=' . $catids[0],
 				'component_id' => 22,
 				'home'         => 1,
@@ -869,9 +875,9 @@
 		{
 			// Set values which are always the same.
-			$module['id']              = 0;
-			$module['asset_id']        = 0;
-			$module['language']        = '*';
-			$module['note'] = '';
-			$module['published'] = 1;
+			$module['id']         = 0;
+			$module['asset_id']   = 0;
+			$module['language']   = '*';
+			$module['note']       = '';
+			$module['published']  = 1;
 			$module['assignment'] = 0;
 

Note: I also added $data->multilang = 0; to the testing sample data.

I don't see any reason to prevent the sample data being installed on a multilingual site.
Neither with or without this PR.

@Bakual
It may be still a good idea to add my proposed code to this PR, setting $data->multilang = 1;
( testing sample data set to 0) as this would be useful for 3rd party or even future core sample datas.

and, in any case, modifying the strings I suggested above in #17488 (comment) to be sure newbies understand what they get.

Removed the "Home" part from "Blog Home".

As for the multilang property. I honestly still don't see the issue you're trying to solve here. I don't see how it is worse when you install the sample data on a multilingual site than on a monolingual one. Even if the set isn't "optimised". All you get is a bunch of data, either tagged to a specific language or to "All". "All" works both in a multilingual and a monolingual site. And it's exactly the same work to remove the data again afterwards.

With latest commit I expanded the description of the sample data set to include a sentence about the behavior when the site is multilingual. It reads now

Sample data which will set up a blog site.
If the site is multilingual, the data will be tagged to the active backend language.

I think that's good enough without getting a wall of text.

I have tested this item ✅ successfully on 785811f

Needs documentation.

I've started some basic documentation as a wiki in the testing sample data plugin repo.

@AlexRed can you please retest?

I have tested this item ✅ successfully on 785811f

Patch ok for me

RTC after two successful tests.