Layouts: keep layout structure across multi languages

Currently when creating a multi language page, the layouts are not duplicated. This means, if you created some extensive content inside a layout for language A, maybe the layouts also including some special settings, etc, all this gets lost when you switch languages and try to input the content for the second language. that is a pitty, because you need to recreate the whole layout again by hand, including settings, etc. It would be great if the layouts field just gets copied like all other input fields for the new language and you only have to change the actual content, but all settings and columns etc are still there

I agree, syncing content of multilanguage websites with blocks (and even structures) is a pain and I think most multi-language websites run into this issue, as a translation is mostly a variation of the same content structure. In production context, this leads to many content not being translated and simply forgotten in translations.

#254 will facilitate manual synchronisation but there should be an option to always keep the blocks, layouts and structures in sync with other languages.

See this related forum post :
https://forum.getkirby.com/t/multilanguage-content-synchronisation/23930
And my experimental plugin, which does exactly what you want :
https://github.com/Daandelange/kirby3-TranslatedLayout

Yes please 🙏

To both the mentioned structure and blocks.
And maybe also support translate: false on certain fields in a structure? 👀

Daan your implementation where you can enable translation for the layout and blocks to keep the structure in sync and disable translation for certain fields inside the blocks and the layout settings is a very good solution.

I’m working on a website with layouts and 5 languages right now and I’m considering building it in Kirby 3 allthough Kirby 5 beta 3 is already out, just so that I can use your plugin.

I can’t imagine the pain of having to make the same layout setting adjustment in all 5 languages.

Kirby, please, please, add translations for structures, layouts and blocks, to make improve the UX in multilanguage pages.

funny that felix wrote today in this thread. i just came back from an appointment with a client, i was introducing them the panel and admin areas so they can work on this new website. this was a topic again today. they were very sad to hear that layouts are not synced and if you change one in one language you have to pretty much go though all of them.

Examples:

1. Want to later change the photo of the quote author or the link to the full story? You’ll have to do that in all five languages.

2. Want to re-order your FAQs? You’ll have to do that in all five languages.

3. Want to change an icon? You get the gist.

at this point i think you are not in the right thread anymore. i posted this regarding layout structure. changing an icon in an element (i imagine a block in this case) has more to do with content synchronisation, not layout sync. i think that would be a step further down the line, to be able to use translate: false inside blocks. i know that the topic was mentioned by others also here, by now you kinda are taking over with a topic that needs its own thread :P (but i agree of course, using translate: false in blocks would be great)

Fair point. I think it’s hard to separate: layout & blocks are co-dependent. And syncing blocks between languages will have to go hand in hand with syncing block content that doesn’t need to be translated.

i was just editing my message… i think they might be more related than i thought to be honest, and hence the solution technically the same at the end? not sure. but i would indeed say we need another thread for translate: false inside blocks and structures ^^ unless theres already one?

in my mind i would separate layouts from the fields they contain. so there would be a layout information, and then a layout-blocks information, just like the one we already have right now. and the layout-blocks information maps the blocks it contains to some quadrants inside the layout information. that way at least layouts remain the same, even thou if you move a block in german it will not move in english. but again, alone having a layout that looks the same in all languages would be nice (or at least to option to activate this feature, in case you need each language to have a different layout)

PS: i cant believe this is only upvoted 17 times :(

Thanks for your gentle feedback :)

@Fellix Sorry, I’m lacking time to maintain my Kirby plugins and this one hasn’t evolved much after the initial draft, so use at your own risk. Plus K3 hasn’t got any security updates anymore. But as you say, the method is simple and works well. I’m still planning to move to K5 but I can’t tell when.

Honestly I was hoping for this feature to make it into the K5 core, but it got postponed again. About once a year, a topic arises with frustrated people moving/creating a website with complex fields (structures, layouts, blocks, etc..) to a multilanguage version, naturally getting stuck. As essential as this feature may sound, there’s only 20 upvotes since k3 so I guess this is indeed not a much wanted feature… But for the 20 of us that need it: for sure it’s a game changer.

This makes me wonder: What’s the part of multilanguage kirby installations compared to single language ? Are like 95% of all Kirby installations single-language ?!?! Or are there more multi-language installations around ? If so, do they simply omit to use any complex fields ? I simply can’t imagine somebody being happy with the current implementation…

Meanwhile we now got UUIDs which could make my implementation more robust. Also: maybe the new k5 translation+preview features may help with this; I haven’t had a glimse at the code yet.

I still think Kirby has the intention to solve this somewhen : there are some mentions of internal todolists needing heavy refactoring before being addressed.
And I’m guessing : that internal feature is nested/recursive fields that reflects the content translations. Fields cannot hold true child fields and that’s what makes “complex fields” overly complex; they have to handle their logics on their own (translation, etc..). The whole page-fields structure is absolutely flat and cannot reflect content retrieval logic past the root field. Complex fields that visually appear as a field of child-fields don’t have real child-fields and are just 1 field that (natively) translates as any other simple field.

PS: If anyone is willing to contribute to kirby3-translations I’m happy to share maintenance.

+1 this could certainly be very helpful!