Blocks: no output on translated page when translate:false

[caplod]

Describe the bug
on Kirby 3.5 content that has 'translate: false' in the blueprint has no output on translated pages.

To Reproduce
I have a blueprint for a block, in site/blueprints/blocks/textmedia.yml

name: Text (mit Bild)
fields:
  text:
    label: Text
    type: textarea
  image:
    label: Bild
    type: files
    max: 1
    layout: cards
    translate: false

In the frontend I render the block with:

<?php
foreach($page->mybuilder()->toBlocks() as $block):
  snippet('blocks/' . $block->type(), array('data' => $block));
endforeach;
?>

Expected behavior
If I edit the translated page block, the text is editable, the image is greyed out, but I see the original image. That is how I think it should be.

In the frontend on the default language the image is rendered but on the translated page, the image is missing?

[afbora]

Similar issue on structure field https://github.com/getkirby/kirby/issues/2790

[hdodov]

We decided to implement localization on our website and this issue forces us to refactor the entirety of it, since our content is mainly stored in blocks. That's soul-crushing...

[MathiasGmeiner]

We stumbled upon the same issue just now!

[squareclouds]

any updates on this?

[MathiasGmeiner]

Would be nice to have a comment from the Kirby team about this issue. Currently we have three multilingual sites (unfortunately all for the same client) and they have a really hard time with the editing process, especially because of pictures inside blocks that should not be translatable but are because of this bug.

[bastianallgeier]

I'm sorry for the silence on this issue. We are struggling big times with fallback logic for nested translated objects. I wish we had a simple solution, but every time we look into it, it's giving us lots of headaches. We will keep on working on this, but we don't have a solution yet.

[MathiasGmeiner]

I'm sorry for the silence on this issue. We are struggling big times with fallback logic for nested translated objects. I wish we had a simple solution, but every time we look into it, it's giving us lots of headaches. We will keep on working on this, but we don't have a solution yet.

Thanks a lot for your reply! I can image that this is not an easy problem. If we can help, please don't hesitate to ask. Currently, any multilingual page feels like a workaround.

[hdodov]

@bastianallgeier it would be a huge breaking change, but the most adequate solution in my eyes is to have a single TXT file for all translations. This way you wouldn't have to merge fallback fields from the default language with the localized fields. It would avoid the issue of having to sync up deeply nested data structures.

You can check how Payload CMS does it. It works out great for them.

[MathiasGmeiner]

After thinking about for about 30 seconds (sorry 😬): could be a good solution! For example, it could optionally be possible that only the standard language can add new entries (e.g. structure field or block elements), the other languages would then always have the same structure and the default content as a fallback.

For smaller, simpler sites we had a workaround with a similar idea behind: Just one language but every field was created multiple times.

e.g.

title_de:
  type: text
title_en:
  type: text
title_fr:
  type: text

[lukasbestle]

We have an internal concept that experiments with getting rid of the translation merging behavior. But our solution would work by always having a content file without language code next to the translation files. This file will then be used for every field that is not translatable. This also allows to translate a model in a secondary language while leaving the primary language untranslated.

This concept is so far only an experiment, so I can't say if and when it will be in the core. But I agree that we need to get rid of the translation merging at some point.

[cedrvanh]

@bastianallgeier any update on this?

[luclucluc]

I couldn't believe that Kirby could have a weakness about this. I spent a whole day struggling with this. Still the same with Kirby 4. Nothing new about this @bastianallgeier ?

[bastianallgeier]

Sorry for the lack of updates. We honestly navigated ourselves into a really difficult situation with the way translations are handled. We are not just ignoring this, but finding the right solution proves to be super hard.