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.
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
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
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 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)
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.
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?
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.
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)
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.
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 :
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…) :
Am I mistaken ? Or using the plugin the wrong way ?