At the time a plugin is loaded, Kirby does not yet know the language of the page that is displayed. This is a problem if a plugin wants to load it’s own language files (like my Uniform).
In Uniform v2 I used a
uniform helper function that is called in the controllers of all pages where the plugin is used. Whenever the function is called it checks the language (which is known at the time a page controller is executed) and loads the appropiate language file.
In Uniform v3 I wanted to change this behavior and instantiate a
Form class instead of calling a helper function. But this also removes the possibility to dynamically load a language file for multi-language sites. I now implemented a
uniform_language helper that can be used in the regular language files to load Uniform’s language variables. But I’m not completely statisfied with this solution.
How do you load language files in your plugins?
I thought about improving the Kirby extension registry so plugins can register their own language files there, too. This is probably not very straight forward to implement. What do you think about that?
+1 for a language file registry from me, that makes a lot of sense. Would you mind opening a GitHub issue for this? I can’t promise that this will be in one of the next releases, but it’s a great idea.
Yep, a language file registry would be great.
The autogit plugin uses a class method for the translations, which is fine as long as you only need the translations within the class.
In my logger plugin, which is partly based on the autogit plugin, I ended up moving the translation function to a helper function, so that is available everywhere.
I am also currently in the middle of a project where I need to figure out how to handle translations in a more modular fashion. I think a registry would be a good Kirby-esque way to handle this. Kirby core could then easily load all the distributed files before the main language file and I wouldn’t have to worry too much about when to load my custom plugin translations and how to still make them customizable by the site implementation.
@jenstornell Your code works because you don’t use the language detected by Kirby but
visitor::acceptedLanguageCode. Is this always the same?
@lukasbestle I’ve opened the issue.
I’m now using a class method for Uniform as well. As the class is always instantiated when the plugin is used this should work fine.
No, users can also visit different languages than their “native” one.
For now, I have decided to go with a slightly different approach for loading my own language files:
The only place where I can “hook” into the Kirby language file process is the language file itself, I just go with PHP language files for my site and from there call into my plugin code that loads the plugin language settings. This way - if I add my custom code to the top of the language files - I can still override the strings defined in the plugin.