Setting up multi-language support in Directus is currently both time-consuming and complicated. The default CMS templates are designed for a single language, and when building a multilingual setup, we often have to place almost all fields into translation collections. This approach makes the admin panel more complex and doesn’t work well with dynamic structures.
In some CMS platforms like Strapi, multi-language management is much more user-friendly. For example, you can select a language variation for each page from the top bar, and the schema automatically adapts to that language. If Directus had a similar mechanism, the process would be much more efficient for both content managers and developers.
Is the Directus team working on this area? Are there any plans for future releases to make multi-language support more integrated and easier to manage?
Hi there 
Welcome to the community!
Thanks for sharing this feedback. And we’re always working to improve the product.
I’d love to make multilingual support less complex for content editors and developers alike, but if I submit a feature request or a ticket with the scope “make it better”, our core engineers are either going to laugh me out of the room 
or breakdown crying 
.
Could you provide some more specific details on what’s not working well and what you’d like to see? The more detail the better.
- Are you referring to localizing the actual content stored in your Directus collections? or managing translations for the App Studio itself? like collection names, field names, etc? I’m assuming the former, but helpful to clarify.
- What specific part of the setup felt most complex? Was it the initial configuration, managing translations, or something else?
- When it comes to managing translation content, we get a lot of feedback that the side-by-side translations interface interaction is super helpful. And that being able to see a “base” language you’re translating from compared to the “target” language - a side by side view is ideal. Are you saying that Strapi’s interface is better for this task? Or you’re talking about the setup side involved to enable this translations interface?
- Would a CMS template with translations already 100% configured be valuable here? Or is your data model unique enough that this would just create extra work?
- If I remember correctly if you’re using the Strapi equivalent of our M2A relationship (Page Builder), which I believe they call Dynamic Zones, means that you could have different types of content (or blocks) per locale. So in essence, the same page could have a different layout based on the locale. Is this ideal? Is this not ideal? Seems like you have to recreate the structure for each locale in addition to translating the content
- Our (Directus) current implementation allows you to be selective about the fields you want to translate. So if there’s a couple fields that are “universal” or that would have the same value across locales, you don’t have to include those. I think with Strapi’s approach, it’s all fields within that collection become translatable right? Or is it flexible enough to allow you to pick only certain fields?
Hi,
First of all, thank you for your response. Since my English is not very good, the tone of my initial request might not have come across well, so I apologize for that. I also want to thank the Directus development team for their great work.
Here are my answers to your questions:
1. I want to translate the content stored in Directus collections.
2. Converting the default CMS theme into a multilingual structure takes a lot of time. If the “initial setup” is created for a single language, adapting it to multiple languages becomes very difficult. I have to move the existing collection content into translation collections, and some structures cannot be cloned, so I end up rebuilding them for translations.
3. The side-by-side translation interface is nice and useful, but creating the structure and preparing it to work that way is difficult.
4. Having a fully multilingual-ready CMS template by default would be great. I believe it should be available out of the box.
5. M2A for dynamic pages is very useful, but for languages that share the same structure, the configuration is still difficult. For example, if we create a block, we also have to set up the multilingual structure for that block. When there are many blocks, this becomes very time-consuming.
6. In our web projects, almost all fields usually need translation. That’s why I mentioned Strapi’s approach being easier — we can build collections freely without thinking about language from the start. When a new language is added, it automatically becomes compatible with the multilingual structure without extra steps. We can also create language variations for existing collections instantly without making any changes to them.
I hope I was able to explain myself clearly. Thanks again.