We have all heard this from a client: “I have a small marketing website and I want it in English too.” It sounds simple, and it can be, but do not make the error to think “it is just a copy of each page, add the language switcher and voila, we’re done!”
In this talk we will dive into the technology decisions we have made, and committed to the Drupal community, in order to answer the question "How can translations of our content for our (Drupal 10-based) website relaunch, also using the layout builder, be managed?"
In this case study we used our company's website. We had to take our Drupal stack into consideration. It is based upon Lupus Decoupled, a fully integrated solution for a headless Drupal which builds upon Custom Elements and Lupus Custom Elements Renderer. On top of that we also use a custom solution that turns our backend into a contentpool that delivers content to multiple frontends. That was our starting point on top of which we added a multilingual functionality layer.
Drupal Core gives us many tools to start with, but to make it manageable, we had to make some decisions. When an entity exists in one language and then it is translated, all the layout builder blocks are cloned and attached to the new translation. How should the system manage an added block of text? The language switcher must also be designed. There are accessibility guidelines and decisions to make about how the language switcher works when a translation is not available. The list goes on.
We will highlight the overall strategy that we have developed, as well as go into some of the finer points of the code.
