Unable to disable localization for relationship fields.

[SalahAdDin]

Bug report

It is impossible to disable localization for relationship fields at collection types.

Describe the bug

When you enable localization for a collection type it enables localization for every field on that collection; we have relationship fields on a particular one, and we don't want those to be localized: they will be ever the same regardless the localized language. So, we go to the content editor and we try to change it, but there is no any option to disable it; we go to the configuration file and we disable the plugin there, it does not change anything on the admin. Also, if you try to prepopulate the page from another language, relationship fields are not prepopulated.

Steps to reproduce the behavior

1. Enable localization for a collection type with relational fields.
2. Create/Edit an object from its collection type.
3. Fill the default language, specially witht the relational fields.
4. Go to the next language.
5. See the relational field empty.
6. Go to the Content type editor and try to disable localization for relationship fields.
7. See the error: no checkbox to disable it.
8. Disable the plugin directly on the code.
9. After refreshing, go to the model and look how localization is still enabled for relationship fields.

Expected behavior

It should be possible to disable localization for relationship fields by the two ways: admin panel and config file.

Screenshots

Record_select-area_20210514211436.mp4

Code snippets

project.settings.json:

    "category": {
      "via": "projects",
      "model": "category",
      "pluginOptions": {
        "i18n": {
          "localized": false
        }
      }
    },
    "tags": {
      "collection": "tag",
      "via": "projects",
      "pluginOptions": {
        "i18n": {
          "localized": false
        }
      }
    },

System

• Node.js version: v14.16.1
• NPM version: 6.14.12
• Strapi version: 3.6.2
• Database: SQLite
• Operating system: Deepin 20.2 x86_64

Additional context

[derrickmehaffy]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/content-internationalization-i18n-beta-is-live/3892/61

[sam-pires]

Hello @SalahAdDin

Here is some additional info about this issue 🙂 (from this forum post)

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.

[SalahAdDin]

Hello @SalahAdDin

Here is some additional info about this issue (from this forum post)

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.

It seems to be very complicated; could we know the ETA for the v4?

Thanks.

[sam-pires]

As soon as we talk about relations and database model it becomes easily complex 😅 I hope it's clear though, if it's not do not hesitate to tell.

ETA for the v4 Beta is this summer.

[terion-name]

@sam-pires are there any plans to rework entire i18n model? absence of parent id of an entity with localizations is a huge pain, including in realm of relations. You relate entities, not localizations. If I have a localized post that has an author - author is one for entire post, not for a locale. If I have an event with translations, registration for an event is to event entity, not to a locale, etc
Entire datamodel of i18n is flawed

[SalahAdDin]

@sam-pires are there any plans to rework entire i18n model? absence of parent id of an entity with localizations is a huge pain, including in realm of relations. You relate entities, not localizations. If I have a localized post that has an author - author is one for entire post, not for a locale. If I have an event with translations, registration for an event is to event entity, not to a locale, etc
Entire datamodel of i18n is flawed

I couldn't describe it better.
@sam-pires

[SalahAdDin]

@derrickmehaffy Is this feature still planned for by the Strapi team? Since it is not in v4 and you removed it from the milestone

We think this should be a must! Not all relationships will required to be localized.

[ibenarobeno]

Any news if and when could we expect relations that are common to all locales (aka not need to be specified repeatedly for each locale)? I can't find it in the Roadmap. Is it something you have quit planning and we need to translate relations forever with Strapi?

[derrickmehaffy]

Closing and locking in favor of the tracking issue: #12538