feat: language:variables root

[afbora]

This PR …

This was a more complex problem than I expected (always 🙈). Because the system should be able to read, update and delete language variables both from the language file and from a custom root. It involves a breakage change, but I wanted to remove the code complexity by creating a separate LanguageVariables object.

Todos/To discuss

• Inconsistencies: Sometimes we call them variables, sometimes translations (e.g. in the k-language-view and the API endpoints). Do we fully want to switch to variables? Then we should make the changes everywhere (with legacy fallbacks for now).
• Do we need to pass $props['translation'] to the LanguageVariables object? Or would it be better to keep them separate, so that LanguageVariables only takes care about the file and its value. And Language has the job to merge both arrays ($props['translation']) and $this->variables->toArray()) together. As well as filtering all keys from $props['translation'] to only write everything remaining to the variables file.
• Update @since tags
• Add unit tests for new/altered code
• Passing unit tests

Changelog

Fixes

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

Features

• New language:variables root

$kirby = new Kirby([
    'roots' => [
        'language:variables' => __DIR__ . '/site/variables'
    ]
]);

Breaking changes

• Language::translations() deprecated, use Language::variables() instead
• $language->translations() returns LanguageVariables object instead array. Use $language->translations()->toArray() or $language->variables()->toArray().

Ready?

• Unit tests for fixed bug/feature
• In-code documentation (wherever needed)
• Tests and checks all pass

For review team

• Add changes to release notes draft in Notion
• Add to website docs release checklist (if needed)

[lukasbestle]

Great solution to move the logic to a separate class. 👍
A few things I noticed while skimming through the changes:

[tobimori]

Excited for this, thanks! Will this include the possibility to add translations (e.g. for the panel) even if the language does not have a content language assigned to it? Some of my pages are German only, but should still have English translations for the panel.

[afbora]

@tobimori In your case; multilingual is not enabled for the frontend, but you want to add translations (for example for blueprint labels) for users in different languages using the panel. Do I understand correctly?

[tobimori]

@tobimori In your case; multilingual is not enabled for the frontend, but you want to add translations (for example for blueprint labels) for users in different languages using the panel. Do I understand correctly?

Multilingual is enabled, but the languages in the panel might differ from the languages in the frontend.
Let's say I have de and en in the frontend, but I want to add a french translation for my field labels etc. as well.

Currently, I have a translations directory and load yaml files from a plugin. (https://github.com/tobimori/kirby-baukasten/blob/main/site/plugins/project-extended/index.php#L20)

[afbora]

If there is no FR language (so fr.php language file), unfortunately it will not load custom FR translations. It will only load the translation files for existing languages from a custom root.

[tobimori]

😦

[distantnative]

Some first comments. Let me know if you think I misunderstood parts of the code :)

[afbora]

@distantnative I did some changes based on your reviews and done some improvements. Would be nice if you take a look when you're available before writing unit tests and last touch 🙌

[distantnative]

Rebased this but moved it to v6 due to the breaking change.