Content Internationalization (i18n) beta is live 🌍

Are you talking about this? Unable to disable localization for relationship fields. · Issue #10322 · strapi/strapi · GitHub

Hello @justus
Thanks for the feedback :+1: It’s made on purpose.
We took that decision to stay coherent with the current behavior on RBAC when you add a new field or CT: by default the permissions are not checked. So that motivated us to apply the same behavior for i18n.
I agree that it’s might not be the fastest way to get roles ready, but we consider that it is safer to hide newly created content (CT, field, I18n activation) by default and then to allow access to it, than the other way around :slight_smile:

Hello @wlixw87

Here is some info you probably wait for :slight_smile:
(cc @glo and @LuisAlaguna)

We don’t take the relations when using the “fill in from” feature because of a technical limitation. In some cases, depending on the relationship type between 2 entities, and depending on the activation of i18n on only one or both Collection-types (CT), recreating the same relation in several locales could break it.
e.g. In the case where i18n is activated on a CT but not on the other one, and where the relationship type is one-to-one, then if we just recreate the same relation in a new locale we break it on the other side of the relation (the other CT) without knowing it.

We thought about limiting the use of some relationship types in the CTB (content type builder) directly to avoid ending up in this kind of situation. But i18n being a plugin we were too limited and it would have been too complex to implement.

To avoid having the same issue when adding a relation manually from the Edit View, we now apply a filter on the relations you can add, depending on whether i18n is activated on one or both CTs you’ll only be able to create a relation to an entity with the same locale.

That’s also why localization is forced on Relational fields.

The good news is that the new db model in the v4 will solve this technical limitation :slight_smile:
I18n helped us identify several limitations in our model and the v4 is here to make Strapi more robust and offer more flexibility.

Feel free if you have any questions.


By the way, talking about relations, we are currently doing some researches on this topic and it would be awesome if you could share some info about your Strapi projects, your use cases, and needs regarding relations in this forum post. It’s gonna help us make the most of the new model in the v4 :wink:

Hi guys,

I’m quite new at the Strapi and I have a problem how fetch localized data using GraphQL. Here I found the information how to query data using REST API, but I cannot find what I’m doing wrong using GraphQL.

This is a JSON structure of response for the default lang (de-CH):

{
“id”: 5,
“locale”: “de-CH”,
“published_at”: “2021-05-11T12:04:23.616Z”,
“created_at”: “2021-05-11T11:56:10.146Z”,
“updated_at”: “2021-05-11T16:44:59.947Z”,
“mainTitle”: null,
“content”: null,
“openDialogButtonLabel”: "Ich abonniere! ",
“seo”: {
“id”: 40,
“metaTitle”: “Kommt bald”,
“metaDescription”: “Kommt bald desc”,
“metaKeywords”: “”,
“preventIndexing”: false,
“cannonicalLink”: null,
“sharedImage”: null
},
“dialog”: {
“id”: 5,
“Title”: null,
“OfferSummary”: null,
“ConfiramtionReminder”: null,
“RepeatConfirmationReminder”: null,
“Clause”: null,
“title”: null,
“confiramtionReminder”: null,
“repeatConfirmationReminder”: null,
“clause”: null,
“offerSummary”: null,
“form”: null
},
“logo”: null,
“localizations”: [
{
“id”: 3,
“locale”: “pl-PL”,
“published_at”: “2021-05-12T17:14:19.643Z”
},
{
“id”: 6,
“locale”: “en-GB”,
“published_at”: “2021-05-12T17:16:01.446Z”
}
]
}

When I test the query without any filters like this:

query MyQuery {
strapiComingSoon {
openDialogButtonLabel
locale
}
}

I get the correct response:

{
“data”: {
“strapiComingSoon”: {
“openDialogButtonLabel”: "Ich abonniere! ",
“locale”: “de-CH”
}
},
“extensions”: {
“enableRefresh”: “1”
}
}

This is a JSON structure of response for PL version (url/page?_locale=pl=PL)

{
“id”: 3,
“locale”: “pl-PL”,
“published_at”: “2021-05-12T17:14:19.643Z”,
“created_at”: “2021-05-07T12:55:24.182Z”,
“updated_at”: “2021-05-12T17:14:19.859Z”,
“mainTitle”: “Strona w budowie”,
“content”: null,
“openDialogButtonLabel”: “Zapisuję się!”,
“seo”: {
“id”: 41,
“metaTitle”: “Strona w budowie”,
“metaDescription”: “Opis strony w budowie”,
“metaKeywords”: null,
“preventIndexing”: false,
“cannonicalLink”: null,
“sharedImage”: null
},
“dialog”: {
“id”: 6,
“Title”: null,
“OfferSummary”: null,
“ConfiramtionReminder”: null,
“RepeatConfirmationReminder”: null,
“Clause”: null,
“title”: null,
“confiramtionReminder”: null,
“repeatConfirmationReminder”: null,
“clause”: null,
“offerSummary”: null,
“form”: null
},
“logo”: null,
“localizations”: [
{
“id”: 5,
“locale”: “de-CH”,
“published_at”: “2021-05-11T12:04:23.616Z”
},
{
“id”: 6,
“locale”: “en-GB”,
“published_at”: “2021-05-12T17:16:01.446Z”
}
]
}

And when I trying query using GraphQL like this (with filter):

query MyQuery {
strapiComingSoon(locale: {eq: “pl-PL”}) {
openDialogButtonLabel
locale
}
}

In response I get:

{
“data”: {
“strapiComingSoon”: null
},
“extensions”: {
“enableRefresh”: “1”
}
}

What should I do to fetch Polish version of the Single Type? Thanks in advance for every help

Is it also working for images or text only?

Right now it works for every field by default: it creates a new object, somehow they are linked, but the localization object, let’s say a page, it a new page; hence, you can fulfill it as you want: same image but with different languange, or same video but in another language, different relations, etc. The last one is annoying because, in our case, we don’t want to localize the relationship fields, and right now it is imposible to unlocalize them.

1 Like

Thank you Luis, and before internationalization i18n, how did you implemented multilanguage and images? (Maybe you did, just an assumption)

I never had the need to localize images, but for localizing text I used to create a field with the same name but localization short label suffixed.