Even if it sounds like harsh words, the discussion is of course meant to be purely factual.
I seriously ask myself how it is supposed to work at all with only 2 languages. I agree that the concept needs to be rethought and see this as a challenge to us all. We need to think together about what a solution could look like.
Generally speaking, there should be a option for those of us who need it, that allows you to fix the layout in the main language. In the secondary languages, you should only be able to translate, but no longer be able to edit fields.
The setting translate: false already partially implements this, but the current implementation is not sufficient.
In the meantime, I would like to find a way to implement a multilingual site with layouts & blocks. I donāt think this is possible at the moment, unless you manually match each field and manually check each block for consistency over and over again.
Is this really the case at the moment? or am I missing something, and maybe there is a cookbook or tutorial for a working multilingual website that does not try to realize sections with including childpages (like we did some years ago) but with the Layouts / Blocks possibilities?
I guess it totally depends on how you use those fields. Using the default blocks you get a glorified text editor with image and video capabilities. Adding the layout field to this, itās possible to introduce columns. It totally makes sense to decouple the different languages for this use case. For some language you might want completely different content.
Itās a completely different story if you use the layout/blocks fields for the whole page layout, or how you call it: sections. Unfortunately I donāt think thereās an easy solution for this use case.
I agree that it depends on the use case. I am also not saying that it has to be like this in principle or that the functionality is important for everyone.
For me, using children pages to create the sections (or letās call them blocks) on the parent page doesnāt feel good. The obvious thing is to use the blocks function, that seems to be what it is there for.
And in cases where the page structure should be identical in the different languages, the function discussed here is very important. There may be situations in which the pages look completely different in different languages, perhaps. In many cases, however, the structure of the blocks will be identical. If Kirby took this into account, it would be extremely helpful for the operators of such pages.
Currently I have had to completely remove layouts and blocks fields from this project and build a complicated construct of pages and subpages. This is barely usable and the whole site feels like rm -rf is the best next step. So Iām seriously asking here, how should a multilingual website with Kirby currently be realized? Maybe Iām missing something? I would really appreciate some guidance. This is serious.
Proposed solutions have already been made here, it would be great if we could start a team discussion, e.g. with the translate approach.
Thatās what I was trying to explain. I donāt think thatās what blocks are there for. The main use case of blocks is a WYSIWYG editor.
I think it would help to clarify what doesnāt feel good about using pages for that. For very complex websites I feel like having separate file pools per section and generally better performance is actually a big advantage of pages compared to blocks. Thatās why Iām still using my Modules plugin on bigger websites. Especially those with multiple languages.
Blocks field is probably mainly used for WYSIWYG editors, okay.
In combination with the Layouts field, the Blocks field is recommended for creating pages (see Kirby demo from the website, there under the heading āMicrositeā). There, pages are created with layouts and block fields. I also think this is a good and simple approach.
So the layout field is certainly there to create layouts. But what should you do with it if it remains empty in other languages? Rebuilding the structure in every language is somehow not ideal.
However, I can also understand that you handle it differently. I know kirby-modules, of course, and it is an excellent plugin. I have to admit, Iāve lost sight of it a bit. Ever since layouts and blocks fields have been around, Iāve been making websites with it because itās a nice visual way. When it comes to multilingualism, you run into the limitations discussed here. I think itās time to work with kirby-modules again Iāll look into it again now.
Youāre absolutely right. In my opinion the team should reconsider which examples to use or at least add a warning to the docs regarding multilanguage drawbacks. Everyone will run into this issue sooner or later.
Using pages is definitely very different and much less visual. But it seems to be the only way to manage complex multilanguage websites with Kirby.
hello everyone. this is in fact one of the top pain points of kirby, also in my opinion. I think mainly the big problem is that ālayoutā is being handled as a field type, when, at least for me, it should be a section type or something like that (at least conceptually, inside the .txt it would obviously look like a field anyway). as many have stated already, the most common use case is, you build a skeleton in the main language and then you populate it in the other languages. if someone is using layouts, i would dare say +80% of the time that is going to be the use case. so making ālayoutā a structurally more important element (not only a field) is maybe the way to go? and i know/assume this would mean a huge change, but at least in my case, i have been using layouts since they came out. they give a lot of flexibility with the blocks and the settings. i cannot imagine using kirby without layouts anymore, unless the customer has every piece of information already ready so page blueprints can be written in stone and each section of each page can be done without blocks and/or layouts. which is certainly possible, but costs more time in the planning phase so the concept is airtight since we donāt have the added flexibility.
right now i am also working on a new project. initially it was planed only for one language and i was prancing and dancing with layouts and nested blocks. now suddenly itās 3 langs not much to do now but train the customer enough so they understand where errors could happen while maintaining the website.
hopefully a solution can found for this in the near future
@thguenther: First of all I used your great plugin in the past and will use it now for a new project ā for itās a multilang siteā¦ Some sections donāt have a title, so the editor has to come up with something to make them unique - a way to auto-generate the slugs instead of basing them on the titles would be great.
Iāll look into it again now.
not much to do now but train the customer enough so they understand where errors could happen while maintaining the website.