"Plugins" menu item translation error on narrow screens

[michalkleiner]

Context

When using Matomo on a narrower screens (990px and below), the menus change into a hamburger and meatballs menu. When viewing the settings/administration, the Plugins menu item errors in this view with a missing translation as per the screenshot.

Expected Behavior

The menu item for Plugins displays correctly in all languages including the number of plugins to update.

Current Behavior

For wider views where the menu is generated by PHP it all works correctly, but for tablet and mobile views the JS menu is broken for the Plugins item.

Possible Solution

All other items use the translation key as the name of the item and translations are provided to JS via getClientSideTranslationKeys(&$translations).
For the Plugins menu item, the key for the menu is the actual translation itself due to the need to add the number of available updates to the item. For PHP this falls back to the text itself, but for JS it can't find the correct General_Plugins key as it's not used.

One potential solution would be to add a new General_PluginsWithUpdatesAvailable key and use that conditionally based on the available updates. That way the frontend would have the correct key to use. The question remains about how to pass the additional value with the number of plugin updates to the frontend. Possibly would need enhancing the FE menu mechanism to support this.

Steps to Reproduce (for Bugs)

1. Visit /index.php?module=CoreAdminHome&action=home in a window with below 990px width
2. Open the hamburger menu, open the System item
3. Observe the issue

Your Environment

• Matomo Version: 5.x-dev latest
• PHP Version: 8.2
• Server Operating System: MacOS
• Browser: Brave
• Operating System: MacOS

[sgiehl]

Another possible solution might be to simply pass the menu entries translated to the frontend components. That way we even wouldn't need to pass them to the javascript translation array...

[caddoo]

I had a look into this with @bx80 .

The reason we can't do all the translations in PHP is because we don't know what plugins are already hooked into the admin menu, and can't make them all pass in translated names suddenly.

What I know

• Works for the normal viewport size menu.
• Doesn't work for thinner viewport menu.
• Both menus use the same source of data.

The Menu in CorePluginsAdmin translates the string early and appends a count if needed, something like this for English Plugins(1).

The translation for the wider viewport menu is handled by a twig filter, which in turn utilises the Translator in PHP

This method is much more forgiving when it can't perform a translation. It just returns the original field passed in, which in this case is Plugins(1).

However on the front end side, the translate method under the hood uses _pk_translate which doesn't fail as silently when it can't translate a value.

I have a fix in progress (adding UI tests) which essentially adds this Vue function for the MobileLeftMenu.vue plugin for now.

translatedName(name: string) {
      const translatedName = translate(name);
      if (translatedName.includes('was not loaded in javascript. Make sure it is added in the Translate.getClientSideTranslationKeys hook.')) {
        return name;
      }
      return translatedName;
    },

Meaning both the twig filter and the front end translate behaviour is the same.

This isn't the ideal solution however there is already work be done by @bx80 on adding nice badges to the top menu, which doesn't require appending strings to the name of a menu item.

Once that is done, we should look to add those badges to this menu as well for this use case and others.

[sgiehl]

Introducing a "more forgiving" javascript method doesn't sound like the optimal solution to me. The real problem is, that we do the translations twice for that specific item. Normally menu items should be added with their translation key only. This is "needed" as events to filter or sort the menu need to be able to rely on a static name. This currently already fails for the Plugin menu. So the correct solution would more likely be to remove the possible update count from the menu name and implement a solution how to add that in another way. Afaik menu entries can be added with defined custom attributes to be added to the link elements, not sure if that is also the case for the mobile nav. But maybe this could be used to append the count using CSS or similar.

[caddoo]

I believe @bx80 is already working on updating addItem in MenuAbstract to support badge count, once that's done, we can revisit this.

For now I can just fix it for plugins by removing the badge count altogether and not translate it so early.