Content Internationalization (i18n) beta is live ๐ŸŒ

  • 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** *

We have run into this issue when trying to update a filled in version of the default locale, updating the default locale seems to work fine. Odd thing is that our component had no unique fields that it is failing for, so it must be related to something with the localisations, having rolled everything back to 3.5.3 and removing any localisations entries in the database everything is back to normal.

We also managed to get filtering working by using gatsby-source-graphql and using a where clause.

I guess we will wait for the stable release before taking it further than staging for the moment :slight_smile:

I have a problem, I created a collection of pages with a dynamic creation of sections with the dynamic zone and I would like to transform the page just created in Italian into English, but Iโ€™m seeing that once created the page in Italian which is the default language if I go to select Internationalization โ†’ Locales โ†’ English I have to recreate the whole page then all the dynamic zones โ€ฆ I thought it was possible with this new function of internationalization clone the pages and change the content without losing the structure โ€ฆ at this point I would like to ask if it is possible to clone the page created in default language and somehow assign the second language without losing the structure created with dynamic zone in default language?

Translated with DeepL Translate: The world's most accurate translator (free version)

1 Like

I know you can edit permissions, I was just talking about whether or not it makes sense from a UX perspective to only show unlocalized collections as a default. :wink:

I also wanted to report a problem on the single entities, I have applied the internationalization and if I go to select the second language it also modifies the data on the first and sometimes I get the Error: Some of the provided components in item_menu are not related to the entity

Can you provide us with some more context especially regarding the single type model definition?

in this case I can not make the update of the menu in the second language I happened to change the default language template

and I get the following alert
err

in console in the logs I have this erorre
error Error: Some of the provided components in item_menu are not related to the entity
debug PUT /content-manager/single-types/application::menu.menu (682 ms) 400

Is there a way to filter by locale single types in GraphQL? in collection types I can filter using where: { _locale: "it-IT"} but in single types I couldnโ€™t find a way to filter. I didnโ€™t have any issues with REST as I can use ?_locale=it-IT for single types but no chance in GraphQL.

1 Like

FYI all, we have released a new I18N beta version with some fixes, see the below quote or the note on the main post.

I have the same problem after updating to version 3.6.0-beta.1 :pensive: Content Internationalization (i18n) beta is live ๐ŸŒ - #26 by Giandn

Thanks for this plugin! Highly appreciated! Works great as long as no relations are involved. If I put a component inside of a single type with localization, it breaks. Expected behavior: After having saved the values for the primary locale (e.g. โ€œenโ€), I switch to the secondary locale (e.g. โ€œfrโ€) and fill out the various fields, after pressing Save it shall be stored without touching the values having set before for the primary locale. Current behavior: After pressing the Save button, the values for the primary locale are replaced with the ones for the secondary locale (โ€œenโ€ says Bonjour โ€ฆ) Is there something I am missing?

1 Like

Unfortunately, it now doesnโ€™t seem to work at all. Even with unrelated single fields, as soon as I store a value for a secondary locale, the primary one getโ€™s lost :confused:

How about i18n only for especific fields from collectionType?

Hey guys :slight_smile: I added the ^3.6.0-beta.2 to an existing project and everything works just fine - appreciate it! :+1:
I already tried it out with REST/GraphQL as well as with single and collection types. One question regarding the REST API. For single types, the API is really straight forward for me using something like: http://localhost:1337/home?_locale=de-DE.
But for collection types (e.g. a set of pages with a unique slug which helps me retrieving data), it seems like I cannot add _locale to my query string like this:

  • default locale: http://localhost:1337/pages?slug=imprint
  • second locale: http://localhost:1337/pages?slug=imprint&_locale=de-DE

INSTEAD, I needed to set a new slug for the locale and query data like this (see the slug):

  • default: http://localhost:1337/pages?slug=imprint
  • second locale: http://localhost:1337/pages?slug=imprintde&_locale=de-DE

This seems to be kind of annoying ;)) Especially when using stuff like Next.js Internationalized Routing

Is there another/better way of extracting localized data from collection types via the REST API or did I do something wrong in setting up the content type? What do you think about this?
Thank you guys :wink:

Fields inside collections do work nicely. What I reported before happens only inside of single types.

ok i managed to duplicate the page from the default language :slight_smile: it is not very intuitive but in the end i succeeded but I canโ€™t manage the single entities yet, I donโ€™t know if you are working on it or it is not foreseen

We are :wink: Pull requests ยท strapi/strapi ยท GitHub

@DMehaffy
The company I work at plan to use Strapi and I have been tasked with implementing it. Seeing as our goal to have an international marketplace, internationalization is essential for us.

If we were to have implemented all the content we need (without internatilization so just en-EN version of it) what steps will need to be taken to migrate once this beta goes live? Would it make more sense to simply wait?

Thanks for everyones work on this i18n plugin - this is a long time coming, and much needed.

Not sure if mentioned previously, but an issue I am seeing with the โ€œFill in from another localeโ€ feature, is that it is not copying the relationships. An example we have is the โ€œpost_typeโ€ relationship which needs to be reselected after I clone the source locale.

1 Like

From what Iโ€™ve been told by our engineering team, nothing beyond just updating the versions. We are trying to make the upgrade to v3.6.x as easy as possible so it should just be our standard update guide: Update Strapi version - Strapi Developer Documentation

From there you would just need to modify the models to enable I18N on them, then update the fields you want to have localization on.