@chmst Would it be good to use different substring lengths depending on if multilanguage is enabled or not? We would not shorten the string too much when multilanguage is not enabled. Or would that complicate code too much?

And maybe we could check for the length of the actual language code? The languages table allows 7, but in most case it's less. We have to keep 2 characters in reserve because the index number is prepended in the line below the changed code, and the language code will be appended with a dash later in the menutype.

I'm only thinking about how to improve the PR, but I don't request any changes. I'm ok with the PR as it is if it fixes the issue.

@chmst Hmm, I just seer that the language suffix is already appended to the title in row 802, and that is then used for the substr. That seems not right to me.

@chmst I've made a PR in your repo with a proposal so that the language suffix always will be complete at the end. See chmst#14 .

This patch would take off the $langSuffix which is the only way to differentiate in case of same Title (as in French and Spanish).

I would rather suggest to add the suffix AFTER the truncate.
The suffix can be 7 characters long as ISO alpha3 country codes are 3 letters, even if none exists yet.
Exemple : arg-usa could be a valid lang suffix

Therefore we could truncate to 16 indeed and then add the langsuffix

We would have something like.

        // Detect language to be used.
        $language   = Multilanguage::isEnabled() ? $this->app->getLanguage()->getTag() : '*';
        $langSuffix = ($language !== '*') ? ' (' . $language . ')' : '';

        // Create the menu types.
        $menuTable = new \Joomla\Component\Menus\Administrator\Table\MenuTypeTable($this->db);
        $menuTypes = [];

        for ($i = 0; $i <= 2; $i++) {
            $menu = [
                'id'          => 0,
                'title'       => Text::_('PLG_SAMPLEDATA_BLOG_SAMPLEDATA_MENUS_MENU_' . $i . '_TITLE'),
                'description' => Text::_('PLG_SAMPLEDATA_BLOG_SAMPLEDATA_MENUS_MENU_' . $i . '_DESCRIPTION'),
            ];

            // Calculate menutype. The number of characters allowed is 24.
            $type = HTMLHelper::_('string.truncate', $menu['title'], 16, true, false) . $langSuffix;

@richard67
I feel my solution is much simpler.

@richard67 I feel my solution is much simpler.

@infograf768 But you are not appending the language suffix anymore to the title of the menu item?

And in case if not multilingual, the lenght of the suffix is zero, but you still cut the string it to 16 characters. My proposal caters of all this.

@richard67 and @infograf768 thank you for your suggestions.
I am shortening the title, then adding the language.
There is a menu id as prefix. This is is not necessary, it is inherited from former versions and could be cut too.

@richard67
You are right. I guess I should go back to old men TV shows.

It is not important if the text is short or not. It must be unique, that's all.

It is not important if the text is short or not. It must be unique, that's all.

@chmst That's right, and after your last changes your PR is ok regarding that. But you don't append the language suffix anymore to the menu item's title. That's a change compared to before. For me it's ok since they should be translated anyway, so the language code suffix should not be needed there. But it's a change. @infograf768 What do you think?

@richard67 - you are right. This is a change, will redo that.

I would keep the language suffix. It is very useful when you use multiple languages to differentiate what was produced by the sampledata —which will be deleted when one starts to really work on the site— and the menus, menu items newly created.
Best example is when you use de-DE, de-AT, etc.

I have tested this in different variants, using en-GB and en-CA as languages with similiar menu titles. Please test again with other languages and use cases for the installation routine.

I have tested this item ✅ successfully on 3e1535e

Menu list

Sitio
Menu bas (fr-FR)
Menu spécial (fr-FR)
Menu principal blog (fr-FR)
Bottom Menu (en-GB)
Special Menu (en-GB)
Main Menu Blog (en-GB)
Main Menu (es-ES) es-ES
Main Menu (fr-FR) fr-FR
Main Menu (en-GB) en-GB
Main MenuPredeterminado
```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/41846">issues.joomla.org/tracker/joomla-cms/41846</a>.</sub>

@infograf768 - thank you for working on this issue - could you do a test?

Hmm, it seems the menu types with the "Home" menu items get a language suffix appended somewhere else, too, so we have
Main Menu (es-ES) es-ES
Main Menu (fr-FR) fr-FR
Main Menu (en-GB) en-GB
Not a big problem and maybe nothing which could be easily fixed with this PR here, just wanted to mention it.

That's weird. How did you install the languages? During installation or later after installation?
As the Main Menu entry is stored during installation this could make the difference. The main menu entry is not added by blog sample data but during installation.

That's weird. How did you install the languages? During installation or later after installation? As the Main Menu entry is stored during installation this could make the difference. The main menu entry is not added by blog sample data but during installation.

So it seems it's not coming from the PR here. The main menus might have come from installing multilingual sample data first before installing blog sample data for each language, which is a common and handy scenario. The multilingual sample data installation prepares everything right, including the language filter, and then you can do the rest.

I have tested this item ✅ successfully on 3e1535e

The PR solves the issue. I still think my solution would have been a little bit nicer, but only a little bit, any maybe also a little bit more complicated, so I'm fine with it.

RTC