Content Internationalization (i18n) beta is live 🌍

I believe this is intentional for the moment. @sam-pires / @Jab / @maeva can you confirm the reason we opted not to implement this right now (IIRC it’s a technical limitation of the v3)

I’m interested in why it wasn’t very intuitive for you? What could be done differently?

it would be much simpler to clone the page by adding a button next to it + ADD NEW (Name Collection) at the top right with a clone button and then do what you do by clicking on fill …

and then after the click or in the specific page next to the save

I think I’ve understood your plan. The clone idea is good but you have to at least pick the locale you want to create, then explain from which other existing locale you want to pull the content. It requires two steps.

Maybe I didn’t really understand the user flow here.

I’m playing around with the plugin at the moment! Very nice work! :tada::tada:

One thing that I’ve noticed: Is it planned to allow the image alternative texts in the media library to be internationalized?

And another question: We prefer to use the en-US locale instead of en for the moment. Will it be possible to delete the en locale in the future, if another locale is set as default?

Many thanks!

1 Like


great work :rocket:

I still have some questions/problems though:

  1. When using the GraphQL API, the Accept-Language header doesn’t seem to be picked up, am I correct? It works with the REST API.
  2. When querying for a single collection item using GraphQL, no locale parameter can be passed in. If the Accept-Language header had an effect, that wouldn’t be a problem. Is this intended behavior?

Is there something planned like a view or dialog for translators where they can see the original-locale text (e.g. in English) and enter the translation (e.g. in French) right next to it? Such a view (like typical translator tools have it) would be necessary for the work of translators I believe.

It is a good idea but unfortunately it is not planned.
The closest feature would be ‘the fill in from another locale’ button that fills all your translated inputs with one locale.

If you really need such feature the best way would be to develop with a dedicated view.


I’m currently testing i18n plugin with Strapi and I have one question. I have some function like that below


This piece of code create new entries only for my default locale. How I can improve it so that it also create entires for other locales ?

You need to include the locale key and set it to the shortcode, we have our docs PR pending for the dev docs that can give more context:

These will be released on Wednesday (dev docs and user docs), not the I18N feature which I believe is slated for Thursday.

1 Like

Hi everyone,

We have released the beta.3 version of I18N for testing, this will be the final beta release before the stable one. (Assuming no major issues come up).

Rough Change-log is:

  • Fixed an issue with default locale not being set / Switching default locale
  • Fix an issue with localization of media fields
  • The i18n plugin is now installed by default (not enabled, does not affect existing projects that will update)
  • Fix single type delete
  • Fix issue fetching single-type entries that have localization enabled
  • Fix single type updates (PUT)
  • Fix bulk delete on entries that aren’t in default locale
  • Fix sticky header and select the first locale for copy by default
  • Update Buffet.js to 3.3.5
  • Various dependency updates (merged from master branch)

For a more detailed changelog, please review the features/i18n branch on GitHub:

Creating a new project on this beta is the same as before:

npx create-strapi-app@beta test-project --quickstart --no-run (remove the --quickstart and --no-run if you want to test on other databases).

At this time, if you want to test upgrading existing applications there should be no migration steps (minus installing the i18n plugin) but we still do not recommend this version for production usage

If you update your existing project, you do so at your own risk, please do not post bug reports on GitHub until the stable version is released.

If you want to review both the User and Developer docs for I18N you can find them here (please don’t comment on them) and they will be released before the stable on Wednesday.


Awesome feature. Great work! Just tried it out and it works fine with most of my content types. But when I enable it for one specific content type, strapi actually crashes. How/where do you want me to report that issue?

[2021-04-20T14:59:04.305Z] [2021-04-20t14:59:04.304z] debug ⛔️ Server wasn't able to start properly.
[2021-04-20T14:59:04.305Z] [2021-04-20t14:59:04.305z] error Error: Unknown type "updateRecipesInput". Did you mean "updateRecipeInput", "createRecipeInput", "deleteRecipeInput", "editRecipeInput", or "updateRoleInput"?
    at assertValidSDL (/Users/vinzenzweber/Development/rootshealth/glucose-cms/node_modules/graphql/validation/validate.js:107:11)
    at Object.buildASTSchema (/Users/vinzenzweber/Development/rootshealth/glucose-cms/node_modules/graphql/utilities/buildASTSchema.js:45:34)
    at Object.buildSchemaFromTypeDefinitions (/Users/vinzenzweber/Development/rootshealth/glucose-cms/node_modules/graphql-tools/dist/generate/buildSchemaFromTypeDefinitions.js:25:28)
    at makeExecutableSchema (/Users/vinzenzweber/Development/rootshealth/glucose-cms/node_modules/graphql-tools/dist/makeExecutableSchema.js:26:29)
    at Object.generateSchema (/Users/vinzenzweber/Development/rootshealth/glucose-cms/node_modules/strapi-plugin-graphql/services/schema-generator.js:101:18)
    at Object.initialize (/Users/vinzenzweber/Development/rootshealth/glucose-cms/node_modules/strapi-plugin-graphql/hooks/graphql/index.js:76:74)
    at /Users/vinzenzweber/Development/rootshealth/glucose-cms/node_modules/strapi/lib/hooks/index.js:37:28
error Command failed with exit code 1.
info Visit for documentation about this command.
1 Like

Can you give us a bit more information that content-type?

It seems to be an issue with the GraphQL plugin while it creates the schema. I tried to extract the part of my project that would make the app crash and summarised it here:

So after a little testing the one thing that makes all the difference is wether I create a content-type with Display name ending with an “s”. Using “Recipe” as Display name works fine, while “Recipes” would crash the app. Same for “Lesson” vs “Lessons” etc.

@vinzenzweber can you test this PR?


Awesome, that fixed my bug! Love how quick you guys handled this! :raised_hands:

I just installed the newest version, which works great for most of the things, but I stumbled upon some problems (I already mentioned some of them here, but maybe you overlooked it).

When querying with GraphQL, I can only specify the locale for a Content Type which has localization enabled, which makes sense in the first place, but has a major drawback: I can’t populate a relation with the needed locale. For example if I have a Content Type Hotel and a Content Type WelcomeMessage and the hotel has a 1-1 relation with the welcome message and my query looks like this:

query FindHotel($id: ID!) {
  hotels(where: { id: $id }) {
    welcomeMessage {

How is it possible to retrieve a different locale for the welcomeMessage then the default one? As a workaround, I could just query the localizations field on welcomeMessage and filter the content on the client side, which would be less than ideal and not very scalable.

Also, it is not possible to specify the locale when querying a single instance of a collection type by ID (screenshot of the generated schema):

Proposed solution for the above problems:
Instead of always returning the default locale or adding a locale parameter to each and every query, you could simply use the Accept-Language header which every browser sends by default to determine the current content language. This would also work nicely with nested GQL queries.

In the meantime, is there any other possibility to make nested queries fully localized, e.g. by manipulating the context object or something?

It is still in progress and it seems not to be finished any soon as far as I can understand. Is there any workaround documented which we can use as a base?


Hi @sam-pires @Jab : could you confirm you are looking into the possibility to derive localised relationships when clicking “Fill in from another locale” ? My CMS manager is getting crazy :smiley: