I noticed a few plugins having language files and supporting language strings for templates. So for example admin plugin and login plugin support languages. But many plugins don’t have language files and don’t support language strings for themes/templates.
Admin plugin has language strings in user/plugins/admin/languages.yaml. Login plugin has several language files in user/plugins/login/languages/ (e.g. en.yaml, de.yaml). As long as the templates support language strings the different setup of language files doesn’t bother me (and as long as they are complete).
But now I try to adapt e.g. Antimatter theme for German strings and almost the complete template files have strings hardcoded in English. I created an inherited theme and already changed some template files to catch a translated string for output, like in /templates/partials/sidebar.html.twig
{{ "TAXONOMYLIST.POPULARTAGS"|t }}
I suppose creating and editing a language file in the plugin directory is subject to be overwritten when the plugin is updated. So I put my language strings in user/l anguages/en.yaml and user/languages/de.yaml but this way strings for all plugins are in one file per language. After all I feel a little irritated about how to handle language strings and files for plugins when I adapt a theme to support languages. I couldn’t find an answer in the documentation so I thought asking would be appropriate
Is there a naming convention for language strings? (like “.”)
Where should I put language files for plugins and how should I name them? (like user/languages/plugins/.yaml)
Hi Frank, unfortunately not all themes and plugins already have 100% multilanguage support.
What you can do here is help do the work once for all, so all users would benefit from this, and fork the plugin / theme, do the modifications and post a PR (Pull Request) on GitHub to include the changes in the next plugin/theme release.
We have some conventions, to use PLUGIN_PLUGINNAME.STRING (e.g. PLUGIN_LOGIN.LOGIN_BUTTON) and THEME_THEMENAME.STRINGif the theme is provides its own strings too, and put each in the plugin / theme folder’s languages.yaml file (see the instructions we put on http://learn.getgrav.org/content/multi-language#plugin-and-theme-language-translations).
Plugins with tons of strings use a folder structure, like Admin but simpler ones can live with a single languages.yaml file.
I see the main issue with Antimatter is partials/sidebar.html.twig where the plugins code is included, so in this case the language strings translations would go in each separate plugin, so they can be reused by all themes.
Feel free to comment here if you need more guidance in doing this.
Many of the plugins are a community effort, so you are free to contribute and add multi language capability. Or request a multilanguage capability on each of the plugins you’d like to support multilanguage, and they’ll be added to our queue.
All the capability to translate plugins is there. Most of our plugins were developed before we had multi-language capabilities, so all it takes now is to provide translations strings. This is not a complex thing, it just requires people who know the languages and have a little time to help contribute.
Unfortunately people confuse open source for free. There often is a cost, however this cost typically is not monetary, it’s often merely user contribution to help improve the project.
