-
-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New language:variables
root
#6212
base: v5/develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great solution to move the logic to a separate class. π
A few things I noticed while skimming through the changes:
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. |
@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. 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) |
If there is no FR language (so |
π¦ |
7f4acb1
to
178fa70
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some first comments. Let me know if you think I misunderstood parts of the code :)
if ($this->translations()->root() !== null) { | ||
$this->translations()->save($data['translations'] ?? []); | ||
$data['translations'] = []; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about instead of unsetting it here, we do an if-else clause: The if part writes it to the dedicated root, the else part adds it to the $data
array?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If custom root is already set (root !== null
), it empties the data.translations array and writes to the custom root. If custom root is not set, it saves the data array normally as before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I meant:
$data = [
...$existingData,
'code' => $this->code(),
'default' => $this->isDefault(),
'direction' => $this->direction(),
'locale' => Locale::export($this->locale()),
'name' => $this->name(),
'url' => $this->url,
];
ksort($data);
// save translations to the custom root and remove translations
// to prevent duplication write into the language file
if ($this->translations()->root() !== null) {
$this->translations()->save();
} else {
$data['translations'] = $this->translations()->toArray();
}
(not passing anything to $this->translations()->save()
here based on the other suggestion I make below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to empty to $data['translations']
index if custom root defined. Because after few lines later will run Data::write()
and same translation strings to be written to language translations index. $data['translations'] = []
prevents it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But if we don't add it to $data
in the first place, we wouldn't need to unset it, right? Or could $existingData
also have a translations
key?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, $existingData
mean /site/languages/*.php
data and currently languages have translations
key.
src/Cms/Language.php
Outdated
@@ -571,7 +580,7 @@ public function update(array|null $props = null): static | |||
$updated = $this->clone($props); | |||
|
|||
if (isset($props['translations']) === true) { | |||
$updated->translations = $props['translations']; | |||
$updated->translations = new LanguageTranslations($updated, $props['translations']); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work? I thought translations
property is protected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was already protected: protected array $translations
?
c3bc647
to
a18e0ef
Compare
a18e0ef
to
b1b372f
Compare
@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 π |
src/Cms/Core.php
Outdated
'sessions' => fn (array $roots) => $roots['site'] . '/sessions', | ||
'snippets' => fn (array $roots) => $roots['site'] . '/snippets', | ||
'templates' => fn (array $roots) => $roots['site'] . '/templates', | ||
'translations' => null, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question:
I don't have a good idea yet, but wondering if it's too confusing to have i18n:translations
and translations
? Maybe languages:translations
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bastianallgeier What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was our last decision for the language variable permissions? I wonder if we maybe should go the same route here with naming as for permissions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now to be languageVariables.create|update|delete
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could go for language:variables
maybe
I know that it totally clashes with the translations naming everywhere. But I think it makes sense to fully commit to one naming convention here and language variables are at least not giving us any more headaches with the entire content translations vs. ui translations monster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe even i18n:variables
then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure for this PR, @bastianallgeier ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say that it belongs to the language and thus the language namespace feels better to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point there is that so far we don't have a language namespace anyways, we are creating a new one. And what if language is the i18n namespace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still about the root and I think we are mixing them up here. The i18n roots are all in our kirby folder to store interface translations and slug rules. The language:variables root would be a custom project root inside of site.
if ($this->translations()->root() !== null) { | ||
$this->translations()->save($data['translations'] ?? []); | ||
$data['translations'] = []; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I meant:
$data = [
...$existingData,
'code' => $this->code(),
'default' => $this->isDefault(),
'direction' => $this->direction(),
'locale' => Locale::export($this->locale()),
'name' => $this->name(),
'url' => $this->url,
];
ksort($data);
// save translations to the custom root and remove translations
// to prevent duplication write into the language file
if ($this->translations()->root() !== null) {
$this->translations()->save();
} else {
$data['translations'] = $this->translations()->toArray();
}
(not passing anything to $this->translations()->save()
here based on the other suggestion I make below)
src/Cms/LanguageTranslations.php
Outdated
public function save(array $translations = []): static | ||
{ | ||
$this->data = $translations; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public function save(array $translations = []): static | |
{ | |
$this->data = $translations; | |
public function save(array|null $translations = null): static | |
{ | |
if ($translations !== null) { | |
$this->update($translations); | |
} |
Co-authored-by: Bastian Allgeier <[email protected]>
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.Fixes
Features
language:variables
rootBreaking changes
Language::translations()
deprecated, useLanguage::variables()
instead$language->translations()
returnsLanguageVariables
object insteadarray
. Use$language->translations()->toArray()
or$language->variables()->toArray()
.Ready?
For review team