The cleanest model is usually to separate the product identity from the localized presentation.

Right now your Product entry is doing two jobs at once:

• representing the real product, e.g. uniqueID: 123
• representing language-specific data, e.g. translated labels, translated relations, localized text

With Strapi i18n enabled, that means Strapi treats the English product and Persian product as two localized versions of the same content entry. That is expected behavior. If the Product itself is localized, you normally need one localization per language, even if many fields are identical.

What I would avoid is treating yellow and زرد as two unrelated color values from the product’s point of view. They are not two colors - they are two labels for the same color concept.

A better structure would be something like this:

Product
- uniqueID: 123
- color: relation to Color
- usage: relation to Usage
- other non-translatable product fields

Then:

Color
- code: yellow
- label/name: yellow / زرد via i18n

Usage
- code: wall
- label/name: wall / دیوار via i18n

The important part is that the product relates to the concept, not to the translated text. The translated text is only what you display to the user depending on the current locale.

If Strapi’s i18n setup makes the localized Color entries separate entries, I would still keep a stable field like code, slug, or key shared across localizations:

Color EN
- code: yellow
- name: yellow

Color FA
- code: yellow
- name: زرد

That way your application can treat code: yellow as the real value, and name as the localized display label.

For the Product itself, there are two common approaches:

1. Product is not localized
   Use this if the product data is mostly the same in every language and only the labels of related values need translation. In that case, keep Product non-localized and localize only Color, Usage, etc. On the frontend/API side, request the related tag values in the active locale, or resolve them by a shared key/code.

2. Product is localized
   Use this if the product has language-specific fields like title, description, SEO text, marketing copy, localized images, etc. In that case, having one Product localization per language is normal. To reduce manual work, keep shared fields non-localized where possible, duplicate from the default locale, and only edit the fields that truly need translation.

For your case, since uniqueID is the same and the tags are just translated labels, I would probably lean toward option 1: keep Product as the single canonical product record, and make the tag/taxonomy collections responsible for localization.

A practical content model might be:

Product
- uniqueID
- color -> Color
- usage -> Usage
- ...

Color
- key/code
- name/title localized

Usage
- key/code
- name/title localized

Then in your frontend, when rendering Persian, show the Persian localized Color.name and Usage.name; when rendering English, show the English ones. The product itself remains one entry.

The tradeoff is that you may need to handle the locale lookup in your query or frontend logic. For example, if a non-localized product relation shows both yellow and زرد, that usually means you are relating directly to localized records rather than to a neutral taxonomy concept. Adding a stable code and querying/filtering by locale usually makes this much easier to reason about.

If you really need fully localized product pages later, another good pattern is:

---
If my answer solved your problem, you can click **answered the question**. I'm really here to help, and along the way I'm also collecting Galaxy Brain badges haha 😆

Keep i18n enabled on Product, and let Strapi's relation locale resolution do the work you are currently doing by hand. The behavior that helps you is documented but easy to miss: for relations whose target content type is localized, Strapi automatically resolves the relation to the corresponding entry in the target locale when it exists. Localized versions of an entry share the same documentId in Strapi 5, which is what makes that mapping possible.

So the setup becomes:

1. Keep color, usage and the other tag collections localized, as you have them. Make sure each tag entry has both its English and Persian versions (same document, two locales).
2. Keep i18n on Product. Create the English product, select the English tags.
3. Create the Persian locale of that product from the English entry (the locale switcher on the entry, then fill from the other locale). The relations carry over, and because the tag types are localized, they resolve to the Persian versions of those same tag documents rather than staying stuck on English.
4. For uniqueID, turn field-level localization off on that field (in the Content-Type Builder, the field's advanced settings). Non-localized fields keep one shared value across all locales, so you stop typing 123 twice and the two locales can never disagree.

On the API side the same rule applies: query the product with ?locale=fa&populate=color,usage and the populated relations come back in Persian when the localization exists, falling back to unfilled when it does not, which also gives you a cheap way to audit missing translations.

The variant you tried, disabling i18n on Product entirely, breaks down exactly where you noticed: the relation picker has no locale to filter by, so it offers every localization of every tag. That is expected with a non-localized source relating to a localized target, and there is no admin setting to filter the picker by language in that configuration. The two-locale product with shared non-localized fields is the intended shape for your case, and after the field-level tweak the real duplicated work per product drops to one extra click plus verifying the tags resolved.