Plugin apparently affects multilingualism in the panel

[MichaelvanLaar]

With the plugin installed, translations of tab labels of the “Site” view in the panel are ignored. Instead, the English labels from the blueprints are displayed, despite proper translations for the current user language being present in the blueprints.

After removing the plugin, everything works as it should.

Strange enough, this only affects tab labels of the “Site” view. Translated field labels for the “Site” view are displayed in the correct language. And all tab labels are displayed in the correct language when I open any page in the panel. Translations of tab labels are only ignored in the “Site” view as long as the Colors plugin is installed.

This is not a big deal, since I typically set up everything in English as the default language, anyway. And I definitely rely on the plugin’s features. So not using it is not an option. But it is a very strange behavior, totally unrelated to the core functionality of the plugin.

[nilshoerrmann]

Thanks for the report – that's very strange and we never encountered this so far. Which Kirby and plugin versions are you using?

[MichaelvanLaar]

• Kirby version 3.9.6.1
• plugin version 1.7.3

I noticed the issue when I used the Kirby site starter repo (still a work in progress), which I built over the last few months, to create the first real Kirby site based on it. (I’m just starting with Kirby.)

Steps to reproduce

1. Clone my Kirby Site Starter repo, run composer install (and optionally npm install) and run the site locally.
2. Create a panel user and switch its user language to German.
3. Open http://localhost:8000/panel/site and you will see that all field labels as well as system labels are in German, except the tabs.
   
4. Open any page and you will see that the tabs here have German labels.
   
5. To reconfirm that translations for the tabs are actually present, you can check the tabs/uploaded-files.yml blueprint. It is included in the site.yml blueprint as well as in the pages/default.yml blueprint.
6. Delete the site/plugins/kirby-colors folder.
7. Reload http://localhost:8000/panel/site – and now the tabs have German labels.
   
8. Run composer install again to reinstall the plugin.
9. Reload http://localhost:8000/panel/site again – and the tabs labels have switched back to English.

[MichaelvanLaar]

The only “uncommon” thing I do with the color fields is accessing some of them in my config.php (see https://github.com/MichaelvanLaar/mvlkss/blob/244586d481a09ad14025563768be06149ffcfe49/site/config/config.php#L114) to create a color scheme as site-constants.

I will have a look into that. Perhaps this usage causes the strange behavior.

[MichaelvanLaar]

OK, I just played around with “Site” in the panel. There is definitely more strange stuff going on. I cannot save some German fields. New content is not stored in the respective TXT file. Or the new content is saved to the TXT files, but will not show up in the panel.

I definitely have to go through everything I built and search for the error source.

[nilshoerrmann]

We use the plugin on a German/English site ourselves and have never run into this issue. So I suspect there is a more general cause …

[MichaelvanLaar]

Yes, obviously it is something else. And deleting the plugin just “solved” the tab label error, but was not the cause.

I played around with the official starter kit and had no problems.

So I guess, I have to build the hole thing again bit by bit with multiple languages enabled from the beginning and see which step will cause the error.

[MichaelvanLaar]

Inded, the problem must have been something in the code section of my config.php which I wrote to retrieve the color information that was stored in a structure field directly in the “Site” content.

I took the bugs as an opportunity to rebuild the whole functionality around creating a color palette (with variants for light and dark mode, as well as matching contrast colors for each) and making these colors available as a select field in the panel.

Now, selectable colors are defined directly in config.php by referencing Tailwind CSS utility classes. With the help of a small plugin, I make this information available as an additional page method. This allows me not only to retrieve it in templates and snippets using option(), but also to provide these colors as a dynamic option list in the panel using the query property of select fields.

This has several advantages over the previous solution – not to mention that it does not produce any problems in the panel:

1. Defining a color palette is not a task for website editors, and therefore doesn't really belong in the panel anyway.

2. The color values themselves do not have to be defined in two places anymore. Only Tailwind CSS utility classes are referenced in config.php. Brand colors that go beyond Tailwind's own default colors are defined centrally in tailwind.config.js and can then be referenced in config.php in the same way as Tailwind's default colors.

3. In the templates and snippets, I can now directly output the Tailwind CSS utility classes responsible for the color selected by the website editor. The previous detour via additional CSS custom properties is no longer necessary.