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
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?
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.
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
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.
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?
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
Hey guys I added the ^3.6.0-beta.2 to an existing project and everything works just fine - appreciate it!
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:
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
ok i managed to duplicate the page from the default language 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
@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.
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: Upgrade Strapi version | Strapi 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.
