Multi-language support

[andriinuts]

Comment from @olivermrbl:

What

We've included Multi-language support in our roadmap and will likely start scoping mid-next year.

---

OP
Hello, would be nice to have multi-language support. It will make it much easier to manage content for multi-language stores.

[ppsirius]

Is there any plan for that in the roadmap?

[srindom]

Users with multi-language needs generally manage this in a CMS (e.g., Contentful), allowing Medusa only to hold commerce-related data. I like this approach as it doesn't clutter Medusa with data only relevant to the presentation layer. Nevertheless, I would love to explore the options for multi-language support.

Could you add details about why you need this feature in Medusa and not another place in your stack? Would also be great to hear details on how you want the feature to work. E.g., which fields should be translatable, how should different locales be managed, etc.?

[ppsirius]

You could easily pass the translation with i18n and keep it in the repository. Translation of buttons or different constant layout elements does not really need CMS. But that solution is mainly for admin panel, in storefront you should get each translation also for different products so it is more complex rather translating a layout but is possible. We should also think about generated paths for SEO.
Translation could have a huge impact on the adoption of medusa on the market because Shopify or Prestashop give translation out of the box and developers or business pick this solution with less work.

[srindom]

Just to clarify: I am referring to managing translations of things like product names.

Admin translations should be relatively straightforward, although it will require some work to implement an i18n library :)

[speciale]

I could help translating in French and Spanish. Would LOVE to!

[olivermrbl]

As @srindom mentions, there are different multi-language requests in play here.

Regarding translating the admin system, we could proceed without doing much technical design. The only decision we have to make is around what i18n library to use. I'll let @kasperkristensen and @StephixOne make that decision, as they are leading the project's development.

When that has been decided, we would highly appreciate your help with the migration to using the library as well as supporting more languages.

I'll make sure to keep this thread updated regarding our decision.

[mariusa]

For now, but it is improving. It certainly removes a potential blocker, even if not perfectly. There are other blockers on the roadmap for which there are no workarounds.

[dludemann]

For now, but it is improving. It certainly removes a potential blocker, even if not perfectly. There are other blockers on the roadmap for which there are no workarounds.

For you may not be a blocker. For some clients - who pay a lot of money to have a developer develop an e-commerce solution for them - "even if not perfectly" will not cut it. This is most certainly a blocker for a good amount of people and developers and there is no workaround but to use a competitor.

The developers should tackle their roadmap as they see fit, and I'm sure there are other priorities. But whenever this becomes an issue that they would like to tackle, this discussion will help developers with ideas, feedback, and knowledge of how translation would likely be used by users.

[SGFGOV]

A very simple way is to use strapis i18 feature which I have implemented in my strapi repo.. you can query strapi for whenever you need a specific text.. Ideally the translation layer is a part of the presentation layer not a part of the backend or business logic layer.. now you can use the strapi repo repo or your own version..of strapi or another cms

[triplecasquette]

As @srindom mentions, there are different multi-language requests in play here.

Regarding translating the admin system, we could proceed without doing much technical design. The only decision we have to make is around what i18n library to use. I'll let @kasperkristensen and @StephixOne make that decision, as they are leading the project's development.

When that has been decided, we would highly appreciate your help with the migration to using the library as well as supporting more languages.

I'll make sure to keep this thread updated regarding our decision.

Just in case I already use this for Directus UI French Translation:

https://crowdin.com/

It's a very great tools and there's (I think) a free version for open source projects :)

Plus users do not need to edit JSON but there's a cool dashboard for selecting translations and translate it.
And it's synced with the project

[SalahAdDin]

As @srindom mentions, there are different multi-language requests in play here.
Regarding translating the admin system, we could proceed without doing much technical design. The only decision we have to make is around what i18n library to use. I'll let @kasperkristensen and @StephixOne make that decision, as they are leading the project's development.
When that has been decided, we would highly appreciate your help with the migration to using the library as well as supporting more languages.
I'll make sure to keep this thread updated regarding our decision.

Just in case I already use this for Directus UI French Translation:

https://crowdin.com/

It's a very great tools and there's (I think) a free version for open source projects :)

Plus users do not need to edit JSON but there's a cool dashboard for selecting translations and translate it. And it's synced with the project
Wait a minute, does not Directus have internationalization?

[speciale]

Ok. I'm new to the Node universe and I was looking for the possibilities. I saw that there's an i18n and an i18next. If I understood, the second differs as she gives the translation option. Thanks for answering.

[adrien2p]

Just for ref medusajs/admin#405 (comment)

[SaadBazaz]

I like the way Django Admin and Django-SHOP manage it. They have certain fields marked as "translatable fields", then at runtime they use the Content-Language header to determine which language to use to choose the translatable field. This could all be done in Medusa Admin, with some minor UI changes. Although, you might need an additional database table to store translations
@olivermrbl

[herawais]

Odoo also work this way

[dfernandesbsolus]

Vendure have a very good way to make this:

https://github.com/vendure-ecommerce/vendure/blob/master/packages/core/src/entity/product/product.entity.ts
https://github.com/vendure-ecommerce/vendure/blob/master/packages/core/src/entity/product/product-translation.entity.ts

[SaadBazaz]

Yeap. That's a good way to do it.

[dfernandesbsolus]

I started doing this, but I don't have time to finish this now.

import { Column, Entity, Index, ManyToOne } from 'typeorm';
import { TranslationEntity } from 'typeorm-translatable';
import { Product } from './product';

@Entity()
export class ProductTranslation extends TranslationEntity<Product> {
  @Column()
  title?: string;

  @Column('text')
  subtitle?: string;

  @Column('text')
  description?: string;

  @Index({ unique: true, where: "deleted_at IS NULL" })
  @Column({ type: "text", nullable: true })
  handle: string | null

  @ManyToOne(
    () => Product,
    product => product.translations
  )
  source?: Product | undefined;
}

[MDmubarak786]

is it available in V2?

[SalahAdDin]

Is it finished? is there any plugin?

[einar-hjortdal]

Multi-language support is often essential, particularly in Europe. I believe taking the approach Vendure has taken is a good option.

I disagree on relying on a third-party CMS as a solution. I can see using Strapi as a solution for blogging, or to manage pages, but not to mirror data structures in the Medusa database.

On the other hand, I do not care for admin frontend translations but if the capability is provided the community will take care of those. What I am concerned about is exclusively product, shipping and payment-related data that is to be displayed to customers.

22/04 update:
I have looked at the sqlite database schema created by medusa, including inventory and stock location modules (I do not know TypeORM so I can only analyze the raw schema).

The changes I would do:

1. Create a table containing locale codes

CREATE TABLE "locale" (
    "id" VARCHAR PRIMARY KEY NOT NULL, -- generate entity id
    "code" VARCHAR,
    CONSTRAINT "UQ_generate-entity-id" UNIQUE ("code")
  );

Locale codes are necessary to ensure the user selects a locale that exists (no typos, etc.) and to ensure translations relations. These locale codes may be copied from a good list. Strapi has a good one here.
Here is the discussion the Vendure developers had about locales.
2) Add a default locale_code to the store table.
Set to en by default but can be changed by an environment variable at setup time, and/or through the admin frontend. This default locale will indicate the locale used for the default fields already available in the current database tables.
3) Add a store_locales table, analogous to the store_currencies table: this table contains the locales
available to the store.

CREATE TABLE "store_locales" (
    "store_id" VARCHAR,
    "locale_code" VARCHAR,
    CONSTRAINT "FK_generate-entity-id" UNIQUE "store_id" REFERENCES "store"("id"),
    CONSTRAINT "FK_generate-entity-id" UNIQUE "locale_code" REFERENCES "locale"("code"),
    PRIMARY KEY ("store_id", "locale_code")
  );

4. Now create tables that should contain translations. These tables use the parent table id and locale(id) as primary key. When a locale code is available in the store_locales table, these translations may be available to select. All of these tables should ON DELETE CASCADE on the parent table id.

• "product_translations"("product_id","locale_code","title","subtitle","description","handle","material")
• "product_tag_translations"("product_tag_id","locale_code","name")
• "product_type_translations"("product_type_id","locale_code","name")
• "product_variant_translations"("product_variant_id","locale_code","title","material")
• "product_option_value_translations"("product_option_value_id","locale_code","name")
• "product_option_translations"("product_option_id","locale_code","title")
• "product_category_translations"("product_category_id","locale_code","name","handle")
• "product_collection_translations"("product_collection_id""locale_code","title","handle")
• "shipping_option_translations"("shipping_option_id","locale_code","name")

5. Create tables for translated resources. These are, for example, images that may contain text in a different language. All of these tables should ON DELETE CASCADE on the parent table id.

• "image_translations"("image_id","locale_code","url")

I think I listed all the fields that contain data shown to customers.

[samuelstroschein]

@Coachonko yeah, they are having a discussing they don't need to have. Use BCP-47 language tags instead of creating your own locale set to follow best practices, the recommendation of W3C, ensure interop between external services and ultimately fulfill user needs. BCP-47 is comprehensive for a reason.

[einar-hjortdal]

I believe their concern is valid, perhaps you have not considered how to actually implement your suggestion.

Adding all variations seems like a bad idea, e.g. according to https://datahub.io/core/language-codes#resource-ietf-language-tags there are over 100 variations of English and over 40 variations of French. In practice, a single "English" version of anything would probably suffice (although I say this as an English speaker from England, so perhaps my perspective is too narrow). In any case, I'm pretty sure that listing 100 variations of English in UI menus is not a desirable solution.

Having all possible BCP-47 language tags in a table would result in a giant table and bad performance, the only other options are:

1. Only support one language and let the users add a new language using their desired tag, without enforcing the subset.
2. Enforce a subset.

Observing how other large and successful projects have solved this issue is the best starting point we have to prevent unnecessary complications

[samuelstroschein]

The concern expressed is not about storing language tags but rather a UI question:

In any case, I'm pretty sure that listing 100 variations of English in UI menus is not a desirable solution.

Regardless, Medusa can start with support for language codes only (without subtags) but should plan to be compliant with BCP-47 eventually to follow industry best practices (which exist for a reason). The naming of locales instead of languageTags would already deviate from BCP-47.

---

Having all possible BCP-47 language tags in a table would result in a giant table and bad performance [...]

There is likely no need to store all combinations of language tags. Even if, let there be a million rows with 3-4 MB in data, shouldn't be an issue for SQLite.

[einar-hjortdal]

There is likely no need to store all combinations of language tags.

So do you advocate for a subset of tags? I agree a subset is the best option. Can you provide a viable subset? I am not willing to write one, it is extremely tedious. I am unaware of any existing one that could be used.

Even if, let there be a million rows with 3-4 MB in data, shouldn't be an issue for SQLite.

Please understand that in production Medusa recommends Postgres and not SQLite. Coupled with the slower lookup times, network latency and data transfer will for certain cause bad performance.

[samuelstroschein]

So do you advocate for a subset of tags?

Yes. Just ensure that the tags are valid BCP-47 language tags.

I don't have a list. The list from Strapi & Co. is likely OK. I would ensure that the locales contained in those lists are valid tags in the language tag registry and gradually add tags as required.

[luismelloleite]

I am willing to translate the project into Portuguese. Let me know if it is ever needed.

[rico-c]

Is there an expected time we can use this feature? Need it for sure

[mj-mehdizadeh]

I added react.i18next to "admin-ui" and update most of the keywords to support i18n, I created #4190 pull request.

[dfernandesbsolus]

Thanks @mj-mehdizadeh maybe we need to split this discussion in 2 topics, one for frontend translations and one for backend (products/attributes).

[huotarih]

Interested in this so following.
Would be nice to have a multi-language option for the products and categories and everything basically.

[boardmain]

Following this thread ... multi-language is the only thing I'm waiting to start using medusa with my customers....

[herawais]

same here, lets collaborate and add this feature.

[KarthikS373]

Well I am also interested in collaborating and working on this feature

[samuelnunex]

Show

[luluhoc]

The localization for categories, products, etc is a must-have..., right now there is almost none of the e-commerce platforms that have localization and multi-currency checkout are available worldwide.

[olivermrbl]

We are currently working on tooling, that will allow you to add translations to any resource in our core. It will not be natively supported, but shipped as an example in a plugin using a couple of new concepts, that we are excited to share soon.

It will be your job to take this example and rework it to fit your use case.

You can expect this to ship later this month or beginning of next.

[luluhoc]

Great! Thanks for the reply I think I will be using metadata fields for now to translate my store but some of the modules don't support metadata like categories preview feat.

[pablobarcos]

@olivermrbl Is there any news about it?

[yersultanur]

@olivermrbl Hi, is there any updates on this, waiting for this feature

[1lyad]

@olivermrbl Yo man. Any updates?

[earmellin]

Hello, is there any news about this update?

[SalahAdDin]

Two years and yet there is not support.

[TheGP]

@SaadBazaz 3

[gtomaka]

/

Hi, I'm posting a plugin I created. I had a case where the project needed the ability to easily translate product data, but no PIM or CMS was needed. Initially, I thought about writing a native feature for Medusa, but after doing some research, I decided to integrate with Tolgee.

I think it's great software that fits very well into the Medusa stack as it's also open source. Thanks to the integration, I was able to deliver more value much faster with tolgee features such as AI translation assistance or collaborative workflows.

You can read more about this plugin, its features and implementation status in the repo description.

Github repo: https://github.com/rigby-sh/medusa-multilingual-tolgee
NPM: https://www.npmjs.com/package/medusa-multilingual-tolgee
Tolgee: https://tolgee.io

Maybe someone here will also find it useful. 🙌

[SalahAdDin]

better if we don't need any extra service to pay.

[haf]

[SalahAdDin]

Yet we have to pay, there is a fee, and a fee system.

[czw333221]

/

Hi, I'm posting a plugin I created. I had a case where the project needed the ability to easily translate product data, but no PIM or CMS was needed. Initially, I thought about writing a native feature for Medusa, but after doing some research, I decided to integrate with Tolgee.

I think it's great software that fits very well into the Medusa stack as it's also open source. Thanks to the integration, I was able to deliver more value much faster with tolgee features such as AI translation assistance or collaborative workflows.

You can read more about this plugin, its features and implementation status in the repo description.

Github repo: https://github.com/rigby-sh/medusa-multilingual-tolgee
NPM: https://www.npmjs.com/package/medusa-multilingual-tolgee
Tolgee: https://tolgee.io

Maybe someone here will also find it useful. 🙌

Hello, is it possible to add the function of translating images, different images for different languages?

[drloloto]

Well done!!!

[matteobaro]

Any news on multilingual feature??
i think is one of the most important feature !
@MedusaNick

[TheGP]

They blocked PR with such functionality below.

[adriablancafort]

We would greately appreciate that the Medusa team tackles the i18n feature.
From my point of view, the translatable fields (like product title, description, etc) should be able to be stored in the database for every language the store is translated to.

[alsherif-khalaf]

This will make Medusa great

[SalahAdDin]

Not in plans yet, right?

[triplecasquette]

This would require separating translatable content from content such as images and making translatable content a separate table via a many-to-any relationship. This could make the database more complex. I don't know if it should be done via an external module. For example, a reference table for each element that can be translated via a key. A language table, and finally the translations of each key with each language. In other words, three additional tables that don't complicate the initial database. What do you think?

[pepijn-vanvlaanderen]

Creating the database structure(s) and extending API routes in a separate module (we have done this for v1, similar to #2003 (comment)) is fairly straightforward to make in a custom module. However extending the Medusa Admin UI should really be done by the core team to make translating an intuitive part of the UI, instead of adding widgets in places where the original content isn't located.

[eugenepro2]

@olivermrbl do you have this feature in roadmap?

That's really need!)

[earmellin]

This is the only feature missing from Medusa that is holding us back from adopting the platform...

[TheGP]

Nope and they blocked PR with such functionality implementation too

[julianlangweb]

Any Updates on this?
this seriously is the only reason why i hesitate using medusa

[triplecasquette]

If you need a translation you can make a PR. I personnally made the french version. :)

[julianlangweb]

hey @triplecasquette its not that i need a different language its that i need multi language support.
like giving a product a french, english, german title, description, etc. and then can show in the frontend the translation of it.
it's a feature every e-commerce plattform has

[noureddine-as]

Same here, I really hope this will come sooner than later, Medusa is JUST AMAZING in every way, except this single aspect.

[CherryNerd]

@triplecasquette I don't want my newly made store to have to rely on the Google Translate for example for the other product names and descriptions.
I've seen on Etsy and other sites how disastrous that can be

[triplecasquette]

I understand... 🤔 There should be a possibility, but it's clearly Medusa's responsibility to add this major feature. Hope you will all find any solution.

[e-Naeim]

I hope this is considered as it's very important and hold us from using the platform :)

[earmellin]

same for us...

[TheGP]

Nope, they actually rejected the PR below

[alex-merget]

any updates here?

[TheGP]

They rejected PR with implementation via meta fields below

[pepijn-vanvlaanderen]

Currently trying to get this PR #13190 through, which could enable some basic translating through metadata fields on Product / Product Variant / Product Collection.

[TheGP]

Quick update: they rejected it, nice 💩

[MedusaNick]

We are working on a solution to expose a hook for this soon. See comments in the PR.

[TheGP]

Hello? It feels like you have agreement with cloud CMS thats why you are blocking such functionality