kirby icon indicating copy to clipboard operation
kirby copied to clipboard

Blocks: no output on translated page when translate:false

Open caplod opened this issue 3 years ago • 14 comments

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?

caplod avatar Dec 17 '20 08:12 caplod

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

afbora avatar Dec 17 '20 09:12 afbora

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...

hdodov avatar Nov 16 '21 14:11 hdodov

We stumbled upon the same issue just now!

MathiasGmeiner avatar Dec 14 '21 14:12 MathiasGmeiner

This issue has been automatically marked as stale because it has not had recent activity. This is for us to prioritize issues that are still relevant to our community. It will be closed if no further activity occurs within the next 14 days. If this issue is still relevant to you, please leave a comment.

stale[bot] avatar Aug 10 '22 10:08 stale[bot]

any updates on this?

squareclouds avatar Dec 22 '22 12:12 squareclouds

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.

MathiasGmeiner avatar May 08 '23 08:05 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.

bastianallgeier avatar May 08 '23 09:05 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.

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.

MathiasGmeiner avatar May 08 '23 11:05 MathiasGmeiner

@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.

hdodov avatar May 10 '23 04:05 hdodov

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

MathiasGmeiner avatar May 10 '23 04:05 MathiasGmeiner

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.

lukasbestle avatar May 10 '23 06:05 lukasbestle

@bastianallgeier any update on this?

cedrvanh avatar Nov 28 '23 12:11 cedrvanh

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 ?

luclucluc avatar Feb 27 '24 10:02 luclucluc

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.

bastianallgeier avatar Mar 06 '24 12:03 bastianallgeier