Content Internationalization (i18n) beta is live 🌍

No, this is not a late April’s fool joke :sweat_smile:
Content Internationalization (i18n) beta is live :man_dancing::earth_africa:

To test it out, run the command:
npx create-strapi-app@beta my-project --quickstart --no-run
cd my-project
npm install strapi-plugin-i18n@beta
npm run build --clean && npm run develop

:warning: Please don’t use it in production, this is just a beta version.
Let us know what you think about the feature in the comments to this post!

And have a great weekend ahead :grin:


Edits from @DMehaffy

Beta Feedback

Please use this forum post for feedback and bugs, please also check the below list before reporting bugs.

Also: seriously, don’t push this into production, there will be database modifications; we will issue an update and migration guide when we release the stable version.

Known Bugs/Issues

  • Unique fields are currently broken due to a unique constraint applied in the database for localized content. We will issue a fix for this next week, the plan being to remove the unique constraint from the database layer and moving it to the application layer Fixed in this commit

Beta Updates

We have just released the I18N 3.6.0-beta.1 with various fixes

  • unique and UID fields validation
  • undefined filter values
  • package version bumps

You can use the same command to create a new project on this version, as before we don’t recommend “updating” to this version currently and there are no migration guides or documentation yet. To see a full history of commits between the versions, see the GitHub commit log

13 Likes

Hi,
I’ve tried adding it to an existing project.

The first error that came up was, that react-query isn’t installed. Installed i manually.
After that the following happened:

error Bootstrap function in plugin "i18n" failed
[2021-04-02T16:28:52.254Z] error TypeError: strapi.entityService.decorate is not a function
at module.exports (/home/gustav/Development/seebruecke/cms/node_modules/strapi-plugin-i18n/config/functions/bootstrap.js:11:24)
at execBootstrap (/home/gustav/Development/seebruecke/cms/node_modules/strapi/lib/Strapi.js:421:14)
at /home/gustav/Development/seebruecke/cms/node_modules/strapi/lib/Strapi.js:426:14
at Array.map (<anonymous>)
at Strapi.runBootstrapFunctions (/home/gustav/Development/seebruecke/cms/node_modules/strapi/lib/Strapi.js:425:55)
at Strapi.load (/home/gustav/Development/seebruecke/cms/node_modules/strapi/lib/Strapi.js:364:16)
at async Strapi.start (/home/gustav/Development/seebruecke/cms/node_modules/strapi/lib/Strapi.js:191:9)

Any ideas? :slight_smile:

You need to delete your node_modules folder and your package-lock.json/yarn.lock and reinstall modules / rebuild the admin using yarn build --clean or npm run build -- --clean

The issue is rather: if you want to add the plugin to an existing project, make sure you bump all existing strapi dependencies to 3.6.0-beta.0 :slight_smile:

Sorry, didn’t see this at first.

Yeah we intentionally didn’t add “update” instructions since we don’t want people to push it out into production and potentially bork their database from rolling back.

Hi! Sorry if this is not the right thread to ask this, but I’ve been playing around with the i18n beta along with the gatsby-source-strapi plugin for Gatsby. Is there an easy way to populate the localizations property in a query? I only seem to be able to access the default locale documents, the localized versions don’t show up in any results.

No we have not integrated any SDKs with the I18N feature since its still in beta.

Congrats on the release of the i18n plugin.

We’re in a pre-production environment. Should we roll this out and properly test or the db migrations will mess everything up?

Some quick notes on the plugin itself:

  • Reference fields (eg: category) are not being synced between locales. It seems like every item from a collection is basically a different entry altogether. I’ve noticed the fill in from another locale feature, but that fills only the content fields, rather than the references. Also manually syncing all of the items seems to be a bit of a pain, is there a plan to have fields that automatically sync between locales?
  • Is there a way or plan to generate a json with localizations for different locales? Is there a way to import this json?
1 Like

The plugin is great, but I didn’t understand how easily fetch data depending on locale. Something like this, for example http://localhost:1337/restaurants?locale=fr, to return all entities, which are in French. For now it returns default locale object with no data from other locale, only with ID inside.

[{"id":1,"name":"name","description":"description","locale":"en","published_at":"2021-04-05T14:39:13.264Z","created_at":"2021-04-05T14:39:11.619Z","updated_at":"2021-04-05T14:47:28.414Z","localizations":[]},{"id":2,"name":"ldfdl","description":"asfdfa","locale":"en","published_at":"2021-04-05T14:47:52.946Z","created_at":"2021-04-05T14:47:51.567Z","updated_at":"2021-04-05T14:47:52.966Z","localizations":[{"id":3,"locale":"ru-RU","published_at":"2021-04-05T14:48:43.688Z"}]}]

If you are working in a staging environment then please feel free, just keep in mind we ourselves haven’t tested this, hence there is no migration guide.

Normal fields can already do this (just don’t enable the I18N option in the field advanced settings)

Relations I don’t believe can be synced yet, but I’ll touch base with the eng team tomorrow when they are back in the office.

For Rest it will be _locale instead of locale, we generally do this with all our “top level” filters like _sort, _limit, and _start

1 Like

Thanks for your reply! Also, that “_locale” filter on the rest api is perfect for what I’m looking for while we wait for a production release. Cheers!

It’s a great feature, but I have a question when are you going to publish it in production? Would it be in end of April or in May?

Thanks for shipping this :rocket:

I have 2 questions:

  • Is it not possible to localize components? Will this be added in the future?
  • I need to import / export translations. will this be supported or do I have to build something custom?

(can’t find the edit button on my last post. where is it? :male_detective:t2:‍♂)

  • Locales permissions seem to be off by default for editors. So any localized collection type does not show up for editors by default. Is this a bug or a feature?

Largely TBD, it depends on feedback and bugs that are found. We didn’t want to put a hard deadline as we want our community to “run it through it’s paces” to ensure we didn’t miss some critical bugs in our QA stage.

The entire Strapi team ourselves are doing our internal QA right now as well, we are testing out this system of parallel QA testing both internal and external. (First time we have done this)

We have a built in system to “copy” from an existing locale but no automation for translations. And Strapi itself has no content-import feature currently, this also applies to I18N

Something we are looking at, it falls into the localization of relations (components are just polymorphic relations, similar to the media field)

Let me poke @sam-pires / @maeva for that one as I’m not sure.

(Sorry on our dark theme for the forum, hit the 3 dots, then the pencil)

image
image

You can modify the editor role, when you enable the localisation on a content type you need to go to the editor role settings and check the rows related to the locale. With RBAC, you can access a content type only if a role has the right to read or create on a locale. If no locale property is checked on a content type it means that a role cannot access it.

We are struggling at the moment to filter using graphql, here’s the query we are trying

  allStrapiMarkets(filter: {locale: {eq: "nl"}}) {
    edges {
      node {
        assetHeading
        changeHeading
        chartHeading
        header {
          description
        }
        priceHeading
        volumeHeading
      }
    }
  }
}

We’re using gatsby-source-strapi to pull in the data, but the filtering seem’s broken, any idea what were doing wrong?

edit:
Here’s what I think is the related issue I opened for gatsby-source-strapi _locale field is not present once project is built · Issue #187 · strapi/gatsby-source-strapi · GitHub

Hello all,

Thank you for this expected plugin !

I installed it on a branch in my local project to try it (v3.6.0-beta.0) ; The Internationalization settings tab correctly appears, and I have added some languages to test, and added the Public Roles’ permissions for i18n listisolocales and listlocales, but I’m facing some issues :

  • http://localhost:1337/i18n/locales still responds a 403 unauthorized
  • I have seen the localisation option in my “Page” collection type (difficult to find at first : pen icon, next to the collection name), but I am using a dynamic zone with components for creating slices in my website, and I don’t see this localisation option in components’ creation
  • In collection edition, on the right panel, I have seen the “internationalization” block, where I can change the language, but when I change this language, it is a new page to create (you can quite easily copy from another language with the usefull link “fill in with another locale”). But if I have 10 languages and if I just want to change a picture in a slice, I have to change it 10 times, for each language ? I believed it would be each text zone which would be translatable (or not), and not the entire collection…

Here is another solution I was trying to use when the i18n plugin didn’t exist : a language collection for managing my available languages + each text zone was a translatable repeatable component with text+link to language which gives this (but there was no controle on missing locale or duplicate locale…) :
image

Am I mistaken ? Or using the plugin the wrong way ?

Thank you

1 Like