External language variables setup no longer works since K4's language views

[bvdputte]

Description

In the past we could require language variables from an externalized file like this:

// in /site/languages/en.php
'translations' => Yaml::decode(F::read(kirby()->root('storage').'/language-vars/en.yml'))

This worked really well with the philosophy of the custom folder setup. Also, it had the added benefit you could setup your git repo in a good way to separate code/content (I'ld consider language variables now "content" in the new K4 setup with the new language view as they are now de facto under control by the panel editors).

As per Sonja's suggesion, I've tried to set this up with a regular php array instead of yaml, like this:

// in /site/languages/en.php
'translations' => require(kirby()->root('storage') . '/language_variables/en.php')

This works great when reading the variables. As soon as an editor creates a new variable, or changes the value of an existing one, the whole array is saved into /site/languages/en.php instead of in /storage/language_variables/en.php.

With Kirby 3 I've never experienced this issue, but there we didn't have the possibility where panel editors could manage those language variables. Would you consider this a regression?

Also, a bit more background about how I usually setup my multilingual Kirby websites: languages can not be added/deleted/edited by editors. It's a dev only thing in my setups, but if we had more fine-grained permissions, this could also be done by a panel admin role. The reason why it's admin/dev only is it could lead to unexpected breakage of things in the frontend (or e.g. when pulling it other content over API's, ...), and I always like to have a developer/admin assess the requested language change. It's also something I'ld add to my git repo and consider "non user manipulated content" (this is also why I externalize language variables to another location). Since K4, we can let panel editors manage language variables via the new language views. I really, really like that feature. But as you can see, it's not blending in well with the way I used to setup sites. I kindof miss more granular permissions: only allow admins to create/delete/update languages and language settings, but do allow editors to manage the language variables (ideally only "edit" and not "create"/"delete")

Expected behavior
No changes in /site/languages/en.php, but in /storage/language_variables/en.php.

To reproduce

Setup a language in /site/languages/en.php and a php file /storage/language_variables/en.php that returns an array with some translations in 'translations' => require(kirby()->root('storage') . '/language_variables/en.php').

In /site/languages/en.php, use following to require the external file:

'translations' => require(kirby()->root('storage') . '/language_variables/en.php')

Go to the panel and add/edit a variable of the English language.

Check the /site/languages/en.php file. The require is now gone and the translations are now moved into this file.

Your setup

Kirby Version
4.0.3

[tobimori]

It'd be great to allow this. I also strictly follow a separation of config (in code) vs. content.

[bastianallgeier]

This is definitely a very valid point. We could introduce a new root for this that is unset by default. If unset, the language file would be used. If it is set, the data would be read from that root.

[distantnative]

Leaving the link for the more granular languages permissions feature request: https://feedback.getkirby.com/606