Empty Layout-Fields (missing structure) in multi-language setup

How can I maintain the structure of the website in a multi-language setup, especially when using the layout field? Surprisingly, the pages in the languages to be translated are now initially empty and the content for each page has to be recreated. This is obviously not what you want. I understand that you might want to remain flexible, but of course you lose a huge advantage because you now have to recreate the content for each additional language. This is very error-prone and manually tedious and exactly the things that should disappear by using a smart CMS.

I definitely want to retain the structure of my layout field in every page. There used to be a 3rd party plugin for this, as far as i understand, but it was developed for Kirby 3 and no longer works straight away with 4.2.

What solution is there for Kirby 4? I would also like to suggest that the Kirby team think about this again, because giving the user an empty layout without taking over the structure is not a good solution.

If I have completely misunderstood something, and there is already a solution for Kirby 4, then I apologize and look forward to a hint

Hi again,
Hereā€™s a link to the topic that initiated the plugin (which I wrote).
But short answer : native ā€œcomplexā€ fields currently have (very?) limited multi-language support.

There is no out-of-the-box sync once a translation is saved. I.e. when you create a page in the default language, you are shown the original content in the translation. Once you save your translation, no future edits are synced.

However, you can copy & paste new blocks/layouts into each translation and then translate them, so it doesnā€™t have to be completely manual.

For my understanding it stays manual all the time, because if i add a new block to the default languages page layout-field, it doesnā€™t exist in all the other languages. So i need to check and edit every page layout-field in every language manually, or did i miss something?

From my point of view, that means the content is going to drift apart quickly because I donā€™t know who has perhaps only added a block in the default language but has not done so in all languages. In this case, sooner or later there will be completely different blocks in the respective languages. The expectation would be that the content blocks of a page in the default language would be available in all languages so that these newly added blocks in the default language can easily be translated in the rest of the languages, too.

@texnixe Could the following approach perhaps lead to a result? Using page.update:after-hook you would synchronize the layout blocks from the default language into the respective additional languages if the respective block does not yet exist there. Conversely, removed blocks that no longer exist in the default language would also be removed from the other languages. The mechanics could be used to achieve a fairly simple sync, right?

return [
    'hooks' => [
        'page.update:after' => function ($newPage, $oldPage) {
            // PrĆ¼fen, ob die Ƅnderung in der Standardsprache erfolgt
            if ($newPage->language()->isDefault()) {
                // Durch alle Sprachen iterieren
                foreach ($newPage->kirby()->languages() as $language) {
                    if (!$language->isDefault()) {
                        // Struktur der Standardsprache synchronisieren
                        // .... (was zu entwickeln wƤre)
                    }
                }
            }
        }
    ],
];

Well, you would end up with untranslated (i.e. mixed) content in your translated pages, unless you also hide those blocks/layouts until they are translated. But then such an approach can work, yes.

And you would still have to go check if newly added blocks/layouts are translated and go translate them. Or implement something that tells you, hey, we have some untranslated (i.e. hidden) stuff here, translate!

The question is nonetheless how you can make sure that a block in the default language is or is not present in a translation. I think as long as you create a pages in the default language and then just translate each block one by one, the block ids remain the same. But itā€™s easy to get out of sync with block ids, I guess.

This is a very interesting topic, and I am also affected by this problem. I created a website in five languages for a client, and I know the problem perfectly.

For simple fields, there is the option of deactivating them in the other languages with ā€œtranslate: falseā€. This would also be great for layouts and blocks to ā€œfixā€ them.

Of course, there are also multilingual pages with entirely different content. In my case, however, the structure is identical in all five languages.

But the problem does not only exist with blocks or layouts. At least with blocks, you can check programmatically if their number is identical.

If you just have a big blob of text like in a textarea field, this would be more difficult, unless you estimate by number of characters (that can, however, differ wildly among languages).

If i didnā€™t misunderstood you, i donā€™t see the problem you describe with a large textarea field because it is only one field. Its content can of course be different in different languages.

However, it is important that the structure (in your example, the one textarea field as an element of the layout/blocks field) is automatically found on all language pages. And if it is not translated, the default language should be displayed (expected behavior). That is currently not the case. That textarea field although existing in the default language is missing in every other language pages layout field.

However, if the field is already missing, a page without content blocks (empty) is displayed. This is a problem or defect of the website.

Since in this use case each page consists of a layout or blocks field, in any other language this is unfortunately initially completely empty. This means that all blocks in the layout would have to be created again and again in each language file and synchronized manually. This is really not a solution in practice and apparently I am not the only one facing this problem.

With the right tips, perhaps we could develop a plugin that keeps the layout blocks in sync across all languages? - Unless the Kirby team plans to solve the problem in the core system?

From my point of view that is okay because therefore itā€™s the default language. It works as a fallback if the rest of the content is not translated to other languages (just like Kirby already does it for normales pages, if there is no translation in the respective language).

At least you can see ā€œOops, there is an untranslated paragraphā€ in the default language.
Thatā€™s fine! This is much better than seeing nothing, as this paragraph does not exist in other languages :slight_smile:

ā€¦ but only in the panel. No blocks that are empty are rendered in the frontend. As long as no container with CSS formatting encloses the block in the template.

Is it not technically possible to lock the ā€œlayout frameworkā€ from the default language for all other languages? And at the same time prevent the deletion or addition of blocks in the other languages?

Something like this would be perfect:

fields:
  text:
    type: blocks
    fixedlayout: true

  layout:
    type: layout
    fixedlayout: true

Iā€™d rather suggest keeping it in the translation blueprint parameter, bubbling up to the individual block-type translation settings.

fields:
  text:
    type: blocks
    # Let childs define their respective translation options
    # Keep structure identical across translations
    translate: falltrough
    # Free translation
    translate: true
    # No translation
    translate: false

And hereā€™s a link to the feature request on Nolt : Layouts: keep layout structure across multi languages

The content should also be editable in other languages. Therefore, translate: false is not the right way to go. Only the layout should be fixed.

Itā€™s the 3 values I suggest for translate, up to you which one you choose :wink:

So let me summarize what I think I have understood:

There is currently no solution in Kirby, and the team is not yet working on this issue, so a short-term solution is not to be expected.

Since we need a solution in the short term or have to resort to another product (which I would like to avoid), the approach for a plugin seems to make the most sense for us. Somehow itā€™s my last chance to get the project implemented with Kirby.

I can imagine supporting either with development capacity or financially. Maybe someone else is interested in supporting this so that it becomes interesting for a developer. Is there anyone here who would like to take this on?

Iā€™d like to port kirby3-TranslatedLayout to Kirby4 but I donā€™t know when at all. Iā€™m currently unavailable. Meanwhile, feel free to fork it or use it as a starting base. :wink:

The main ā€œissueā€ I ran into (but which is legit) is that translations have to parse both the default language (for the structure and the untranslated fallbacks), impacting page load times. Syncing the content on save felt too fragile and ā€œunconsolidatedā€. Saving translations within the default language felt quite opposite to Kirbyā€™s logics, specially the Panelā€™s ones.

Hi @texnixe

I have to question this again because Iā€™m not getting anywhere here. Perhaps you have another recommendation?

I no longer understand how multilingual websites with layouts and blocks should be implemented in Kirby. From my point of view, this is impossible, the way layout and block fields have developed. But maybe Iā€™m missing something.

Here is an example:

We have a page that consists of one layout field. Blocks can be used in the layout field to arrange the sections of the page. Now we have this in 5 languages. This means that after the first change, the 5 languages within the layout field diverge (because the layout field is not in sync).

Now you could synchronize this manually with a little effort on the first levelā€¦

But now imagine that one of the blocks in my main language is a FAQ block: It contains a Structure field with the questions and answers.

Letā€™s assume we have 20 questions and answers in that field.

How are we ever going to synchronize this manually in 5 languages? Thatā€™s over 100 pieces of content to be synchronized manually. Iā€™m completely lost as to how this is supposed to work in Kirby.

Iā€™ve tried various approaches over the last few days. In the meantime, I have removed all layouts and block fields and converted individual sections back into real pages. That works reasonably well, but then we misuse Pages for Sections again and the user experience is really bad. This feels so 2015, or Kirby 1.0 and 2.0. The advantages of layouts or block fields couldnā€™t be used any more. That is no solution, too.

Can you give me a tip on how I can basically set up a multilingual site with layouts / block features? Is there a cookbook or tutorial that I can use to solve my basic comprehension problem? (especially with using layouts / blocks for building pages). Is that something what could be discussed internally to address that problem?

Thank you very much
Andreas

1 Like

I agree with you on all points. I am also facing the same problem. A website (also in 5 languages) recently had to be changed on several pages. The client was overwhelmed with the task of changing the layout in all languages. So I had to take over the issue. This resulted in additional costs for the customer and put unnecessary strain on my capacities. This is not the purpose of a CMS.
Why is there no way to lock the layout in the main language if it is the same in all languages anyway? You get the feeling that multilingualism with Kirby doesnā€™t follow a well thought-out concept.

You get the feeling that multilingualism with Kirby doesnā€™t follow a well thought-out concept.

Those are harsh words for a CMS with great multilanguage capabilities apart from drawbacks in some field types. Yes, itā€™s frustrating, and yes, sites with 5 languages and lots of layout and blocks fields are probably hard to maintain. But do you have a solution? As @daan mentioned, there are some conceptional and performance issues to solve.

I donā€™t think thereā€™s an easy solution to this problem.

1 Like

Those are harsh words

Sorry for the choice of words, but if some functions cause frustration and lead to additional work, this can lead to disagreement.

But do you have a solution?

Not a solution, but an idea: The solution would be to be able to lock the layout in the main language. Just as I can lock the translation for fields. If I delete a block or a layout, it is also deleted in the other languages. This feature should, of course, be optional, as there are of course multilingual pages with different content. Unfortunately, I cannot say how difficult it is to solve this in the programming.

I donā€™t think thereā€™s an easy solution to this problem.

If the realisation was simple, there would certainly have been a change here already. And probably also an update for Kirby 5.