Internationalization

[MattieBelt]

Hey @revolistic,

Because Strapi uses JSON and not XML, I don’t think this will be the case.

[DMehaffy]

@revolistic

Will the new Content Internationalization feature be working with the XLIFF standard and xlf files? Thanks.

Not in this case, it will be based on a model structure, I’ll have more information once we release the public beta later this month

[revolistic]

We are really looking forward to this feature. Would be great if it would be easy to integrate with the Angular i18n: Angular

[DMehaffy]

It will be easy to integrate with all frontend frameworks, that’s what we at Strapi are all about!

[scriptify]

Hello!
I just wanted to check in what the current status is. When can we expect this feature to land?
I’m going to start working on a rather complex project this April, where Internationalization is a must-have.

I’ve seen that there’s a lot of activity on the i18n branch, so it seems you are working really hard towards this

[DMehaffy]

Public beta/experimental build hopefully this week, however the stable version release is being pushed to ensure proper QA. We don’t have an exact stable release date but it will be in April, most likely before or during StrapiConf.

[scriptify]

Awesome, well done!
Will it be possible to make existing model fields multilingual? (I don’t need to do a DB migration, I can just start with a new one)

[DMehaffy]

Yes entirely possible

[karimbadruddin]

Hi DMehaffy,
any update on beta build?

[DMehaffy]

Content Internationalization (i18n) beta is live

No, this is not a late April’s fool joke Content Internationalization (i18n) beta is live To test it out, run the command: npx create-strapi-app@beta my-project --quickstart --no-run cd my-project npm install strapi-plugin-i18n@beta npm run build --clean && npm run develop Please don’t use it in production, this is just a beta version. Let us know what you think about the feature in the comments to this post! And have a great weekend a…

[karimbadruddin]

Hi DMehaffy,
can you please share link for the beta version?

Thanks

[DMehaffy]

I did up above, that thread tells you how to run a test beta project. We do not recommend updating existing projects with the beta version.

[diegotrigo]

Great. Thank you so much!

I added the plugin and I can see it on the plugin’s page and in settings. I add a new locales (so I have two now, being EN the default one).

What’s next? I can’t see anything changed in the content builder OR when entering content.

How do I add another language copy for the same component?

Thanks

[soupette]

You need to activate i18n on your content type.
To do so, you need to go in the content type builder, click on the pencil icon next to the content type’s name, go to the advanced settings and check the “Enable localization for the content type” checkbox.

Then you can control the localisation of each field in the advanced tab of each attribute.

Here are some informations about the localisation:

• when i18n is enable on a content type all relational fields are localised
• the uid field will always be localised due to the unique constraint
• dynamique zones and components can be localised
• Unique fields must also be localised because of the unique constraint

[justus]

@soupette

• the uid field will always be localised due to the unique constraint
• Unique fields must also be localised because of the unique constraint

That’s a bummer. I’d guess in most use cases an ID should identify objects independent of language.

[DMehaffy]

It’s a hard requirement of how we store the information in the database while still keeping database constraints. Setting something as unique applies a database constraint and since all locales are stored in the same database table you can’t have two entries (say english and french) that share the same unique value.

Abstracting them out to different tables in the database means all relations become polymorphic in nature making relations extremely complicated to manage.

[rou9e]

Hey ! First of all, thanks for this amazing CMS.

As I do understand the requirement explained above, this is still a bummer.
It means there is no way to identify an entity with the same but unique textual attribute ?
Like a guid or sku attribute assigned to a product for example ?

[Laith_Qotom]

Thanks for building Strapi <3 and adding the long-awaited localization feature.

@soupette

• Unique fields must also be localised because of the unique constraint

This doesn’t make a lot of sense to me. Uniques should be the same across all locales, technically (coming from RDBMS background) this can be implemented as a unique constraint on two columns.

For those looking for a hack, I’m providing this sample from one of my products. On PostgreSQL I did the following to fix this on the database level:

alter table products
    drop constraint "products_SKU_unique"; // this query deletes the constraint created automatically by strapi

alter table products add constraint unique_sku_per_locale
unique ("SKU", locale); // this one creates a new unique constraint on two columns 

Please note that I didn’t test this on production yet and it might cause problems, so please make sure you know what you’re doing.

this way, SKU will only be required to be unique in one locale.

@soupette please consider rethinking this design,
Thanks!

[Vinnie_Vidi_Vici]

Good intuition re: uniques across locales - it will immediately cause issues with things like NextJS’s dynamic static page generation. @soupette

[Priyanka_Uppalwar]

I am still a bit unclear on how to migrate from _en, _fr to i18n plugin?
Is there a guide I can follow or this is all manual process?