Language snippet is not translated in user blueprint

[chrfickinger]

Description

A blueprint of a page allows to specify a language snippet for title, e.g.

title: my.translated.snippet

This behavior does not work for User blueprints. I have to put the translated stuff right away in the blueprint, like:

title:
    de: German string
    en: English string

[afbora]

I can't reproduce the issue. How do you define the my.translated.snippet string?

[chrfickinger]

Hi Ahment.
I could help myself.
Strings are defined correctly (e.g. site/languages/en.php), but it seems to be necessary to fill in both language files for it to work.

Example: If I have set english as panel language, german must be present as well, otherwise the snippet will not be translated.

[chrfickinger]

i forgot to mention, english is the default language in my project and it is not set.
So, the solution is: Every snippet must be available at least in default language to work.

[afbora]

• Default language is EN
• Secondary language is DE
• Related translation is defined in DE but not in EN

Is this correct?

[chrfickinger]

Yes, correct.

But there is another strange behavior: I added the missing language snippet, but it's not translated into secondary language. Only default language is used, no matter which language is selected.

[afbora]

Weird! Could you post your translation snippet, please? And which Kirby version do you use?

[chrfickinger]

Kirby 3.8.2

site/language/en.php

return [
    'code' => 'en',
    'default' => true,
    'direction' => 'ltr',
    'locale' => [
        'LC_ALL' => 'en_GB'
    ],
    'name' => 'English',
    'translations' => [
        'panel.user.admin.title' => 'Admin',
        'panel.user.admin.description' => 'All permissions',
        'panel.user.editor.title' => 'Editor',
        'panel.user.editor.description' => 'Restricted permissions'
    ],
    'url' => '/'
];

site/language/de.php

return [
    'code' => 'de',
    'default' => false,
    'direction' => 'ltr',
    'locale' => [
        'LC_ALL' => 'de_DE'
    ],
    'name' => 'Deutsch',
    'translations' => [
        'panel.user.admin.title' => 'Administrator',
        'panel.user.admin.description' => 'Alle Berechtigungen',
        'panel.user.editor.title' => 'Redakteur',
        'panel.user.editor.description' => 'Eingeschränkte Berechtigungen'
    ],
    'url' => 'de'
];

[afbora]

@chrfickinger Sorry for late! I've tested with your setup.

"EN language is the default and a string has a translation in EN but no translation in DE, the translation should look for it in EN as fallback. But instead of fallback it looks like panel.user.editor.title."

Here is the issue and the behavior you expect, do I understand correctly?

* Also this is exists for page blueprints not only for user blueprints.

[afbora]

This is because we send the same string as fallback:
https://github.com/getkirby/kirby/blob/3.8.3/src/Cms/Blueprint.php#L321

And the $fallback argument data is returned before the fallback languages translation check:
https://github.com/getkirby/kirby/blob/3.8.3/src/Toolkit/I18n.php#L167-L180

[afbora]

@getkirby/kirby-staff Need your thoughts. Is this an issue can be fixed?

[distantnative]

I'm getting quite headaches trying to debug the i18n class in that regard. Since this gets touched with the blueprint work anyways, we might have to wait for this first as I don't see an easy solution right now.

[distantnative]

@chrfickinger
Coming back to this, I still don't quite find why this would be different for user blueprints. Is it really just a problem for user blueprints or general?

And could you please try if

title:
  *: my.translated.snippet

works instead?

[distantnative]

Nevermind, I think * would be the same here. I have an idea for the solution, but ig question mark if this won't have side effects.

[bastianallgeier]

✅

[lukasbestle]

@chrfickinger For your information: We had to revert the fix for now because there was a regression: #5086
We will try our best to find a more robust fix for one of the next releases.

[chrfickinger]

No worries. Thank you for letting me know

[distantnative]

A fix has been merged into v4 branch. Will keep this open for now until we double check in the beta this has been solved.

[distantnative]

Will be solved in v4