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]

Why isn't Chrome browser translate good enough?

[dludemann]

Why isn't Chrome browser translate good enough?

If you speak two languages and have ever tried using google browser translate, you know that it is not accurate. I personally speak english and spanish fluently and have done comparisons and it just doesn't translate correctly all the time and doesn't always catch the meaning. Google translate is a very "literal" translation.

[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

[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;
}

[Coachonko]

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.

[Coachonko]

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.

[Coachonko]

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

[emilselroos]

I suggest checking out how PrestaShop handles translating in their admin panel UI. In my opinion, they have the best usability for that because they make it very easy to switch between different language versions. Compared to WooCommerce, for example, it's way more simple and saves a lot of time for store managers.

[gempain]

Far from perfect but if someone had the patience to extract all strings from the storefront starter to a json file and replace their usages by something like useTranslations, we could leverage next-intl and product metadata to do the job.

I've written this:

export function applyMetadataTranslations<
  T extends { metadata?: Record<string, any> | null },
>(item: T, locale: string) {
  const metadata = item.metadata;
  if (!metadata) {
    return;
  }
  console.log(metadata);
  Object.entries(metadata)
    .filter(([key]) => key.endsWith(`_${locale}`))
    .forEach(([key, value]: any) => {
      const prop = key.replace(`_${locale}`, '') as keyof PricedProduct;
      (item as any)[prop] = value;
    });
}

which I use this way:

async function getProducts(
  handle: string,
  locale: string,
): Promise<{ products: PricedProduct[] }> {
  // ... 

  res.body.products.forEach((product: PricedProduct) => {
    applyMetadataTranslations(product, locale);
  });

  return res.body;
}

and in my product metadata I have description_de with the German translation, description_fr and so forth.

It's a bit tedious but hey, it works 😄 I just don't have the time at the moment to extract and translate every string from the starter, and I think the Medusa team has been clear on the subject unfortunately:

• i18n Support nextjs-starter-medusa#109 (comment)
• https://medusajs.com/blog/medusa-contentful-headless/

Next step would be to translate the admin dashboard, and it would be relatively the same task of going through every component and translating it. There seems to have been attempts at this already.

[SGFGOV]

the only caveat being, next-intl doesn't currently support static paths with SSR.

[gempain]

Isn't it in beta ?

[halfama]

Looks that this is by far the most requested feature right now. Any chance to see this coming soon?

[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.

[AimanAlmureish]

If there is a json file we can also create an Arabic one. Now I will be using i18 library to translate it into Arabic

[olivermrbl]

Hi everyone.

Multi-language support for Medusa Admin will be shipping this week in #4962. I am aware that this discussion has been split into two - this one being for entity translations - but I wanted to give a quick update for those still tracking admin translations here.

[yersultanur]

@olivermrbl Hi, you have done great job.

I installed fresh medusa backend, but no changes are shown when I try to change the language at the admin panel.

[yersultanur]

`
export const supportedLanguages = [
{
locale: "en",
name: "English",
},
{
locale: "fr",
name: "Français",
},
{
locale: "pt",
name: "Português (Brasil)",
},
]

const backendUrl = window.location.origin
const adminPath = process.env.ADMIN_PATH ? ${process.env.ADMIN_PATH} : "/"

const pathToLoadFrom = ${backendUrl}${adminPath}public/locales/{{lng}}/{{ns}}.json
`

found the issue with translation you added extra / lower original code, it gives errors in console

`export const supportedLanguages = [
{
locale: "en",
name: "English",
},
{
locale: "fr",
name: "Français",
},
{
locale: "pt",
name: "Português (Brasil)",
},
]

const backendUrl = window.location.origin
const adminPath = process.env.ADMIN_PATH ? ${process.env.ADMIN_PATH}/ : "/"

const pathToLoadFrom = ${backendUrl}${adminPath}public/locales/{{lng}}/{{ns}}.json
`

[samuelnunex]

top

[RamonEbneter]

any updates on this? being able to translate products is a must feature and its holding me back from using medusa.
besides that medusa is just amazing! :)

[RamonEbneter]

@olivermrbl Any Statement on this one? Will this ever be on the roadmap?

[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.

[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.

[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.