Radio / Select field localisation

Kirby 3 Questions 🤔
,
1

Hi,

I’m currently translating a site’s panel (the site is NOT multilingual, but the panel will be available in two languages). Instead of writing the language specific labels into the blueprints, I use placeholders and insert the translations into a plugin like so:

Blueprint:

fields:
    headline:
        label: labels.headline
        help: labels.headline-help
        type: headline
    info:
        label: labels.info
        type: textarea

Plugin:

Kirby::plugin('site/translations', [
    'translations' => [
        'en' => [
            'labels.headline' => 'Test Headline',
            'labels.headline-help' => 'Help text',
            'labels.info' => 'Info'
        ],
        'hu' => [
            'labels.headline' => 'Teszt Címsor',
            'labels.headline-help' => 'Segítő szöveg',
            'labels.info' => 'Infó'
        ]
    ]
]);

So far everything was translatable as expected, but I got to a page type that uses radio and select fields. I can not figure out how to set the placeholder values in the options array in these fields as they are never translated but the placeholders are shown.

This is not translated:

type:
    label: fields.type
    type: select
    options:
        text: fields.text
        number: fields.number

But this is actually translated:

type:
    label: fields.type
    type: select
    options:
        text:
            en: Text
            hu: Szöveg
        number:
            en: Number
            hu: Szám

How can I use translation placeholders in radio / select options? Thanks!

Note: the field’s text is not used on the site, only the value in logic.

2

@texnixe do you have any idea? Thanks!

3

@bastianallgeier maybe do you have any idea? Thanks!

4

Anyone? I’m 95% ready with the panel translations but can’t finish it for a month now.

5

What you want to achieve is not supported for options, what you could try is a php blueprint: Blueprints | Kirby CMS

6

Thank you for the reply. Could you please clarify why this is not supported and is it planned to be supported?

Using placeholders instead of burning in the values of different languages helps the separation of concerns, it keeps the blueprints shorter and easier to understand, also translators don’t need to read / understand YML files. @bastianallgeier do you agree?

Using placeholders for labels is not my idea, the Kirby Core is build this way as well, the translations are separated. For example take the Image Block:

All translatable strings are using placeholders, for example the first line:

name: field.blocks.image.name

This is the English file for the translations: kirby/en.json at main · getkirby/kirby · GitHub

In my example above, I just try to do the same. Also, using plugins for translations instead of inserting the values directly into the blueprints is something the documentation suggests: Translations | Kirby CMS

7

I can only tell you that it is currently not supported, but not why. Maybe it wasn’t requested yet. You can create a feature request at https://kirby.nolt.io/

8

I created the feature request (Allow all Panel fields to be translatable by placeholders · Kirby Feedback) but I’m still not sure if this would be a new feature and not a missing edge case of an already existing feature (labels being translatable with placeholders).

I also noticed in the meantime, that although neither select nor radio support placeholders under their options property, toggle actually does support it under its text property. This is another reinforcement for me, that I noticed a missing edge case while doing a full admin panel translation with placeholders.

If it’s possible, it would be great to hear a second opinion on this case. @texnixe could you please involve someone from the team?

9

I think this is because language variables (I’d prefer this term because placeholders can be misleading in the context of fields) for these use cases were introduced later and therefore are not implemented everywhere. So you have done the right thing to create the feature request.

You can work around the options problem by creating the blueprints programmatically with PHP: Programmable blueprints | Kirby CMS