Support multiple Tolgee instances on one page

[kushuh]

There is a feature in react-i18next (looks undocumented) that lets you hot swap the i18n instance using props:

import { useTranslation, Translation, Trans } from "react-i18next";
import i18nInstance from "./i18n";

function MyComponent() {
  const { t } = useTranslation("ns", { i18n: i18nInstance  });

  return (
    <>
      <Trans i18n={i18nInstance} {...} />
      <Translation i18n={i18nInstance} {...} />
    </>
  );
}

This is immensely helpful when working with internal packages, as each package can use its own i18n instance (and translation source) without conflicting with the top-level provider.

import { Component, Sync } from "my-package";
import i18n from "./i18n";

function MyApp() {
  return (
    <I18nProvider i18n={i18n}>
      {/* Sync component is used to sync the language */}
      {/* of the package with the application. */}
      <Sync i18n={i18n} />

      {/* Component uses its own i18n instance and */}
      {/* translation source. */}
      <Component />
    </I18nProvider>
  );
}

Can such feature be considered with Tolgee ?

import { useTranslate, T } from '@tolgee/react';
import tolgeeInstance from "./tolgee";


function MyComponent() {
  const { t } = useTranslate("ns", { tolgee: tolgeeInstance });

  return (
    <>
      <T tolgee={tolgeeInstance} {...} />
    </>
  );
}

[stepan662]

Hey, unfortunately using multiple instances is a bit more problematic with Tolgee SDK than with plain i18next. The issues lies mainly on the in-context feature, where this brings some issues:

• each instance has it's own mutation observer running, which is not good as observers are running globally, so we would need to somehow distinguish which instance is responsible for which translation
• Tolgee Plugin would need to be adapted to be able to handle multiple instances

I was actually considering this scenario and it is definitely solvable, but so far we didn't have many requests to implement this, so we didn't move forward. I'm not able to give a promise if and when we'll implement this. However, it would be really useful for me to evaluate if I at least have a good understaning of how this would work. I was considering a scenario like this:

• I have a library of custom components which have a translations in them (Project 1 in Tolgee)
  • If used as standalone (e.g. in storybook), all the components would be wrapped in <TolgeeProvider> referencing Project 1
• I use them in an application which also has a translations (Project 2 in Tolgee)
  • Here we would have two <TolgeeProvider> components
  • components would use the one referencing Project 1
  • the rest of the app would reference Project 2
  • You should be able to provide separate api keys for Project 1 and Project 2, so then you would be able to use in-context.
  • The Tolgee Plugin would display two separate instances (I think the instances would need to be named somehow, so you can distinguish which one is which in the UI)
  • The language would be synchronized between the instances
  • On production each instance would load the necessary files independently (however it would be nice to be able to do it in parallel instead of cascade)

Is this the way how you use i18next?

[kushuh]

Thanks for the detailed answer!

This is an accurate depiction of my current usage of i18next.

I have a package that handles authentication, and comes with its own translation for the login UI (Project 1). I want to use it across a few clients, each client being (ideally) its own project, with its own translation context (Project 2, 3, ...).

To expand on my answer from the previous issue, I managed to find a "workaround" by using a single Tolgee project for both my package and applications. Then each application is responsible for providing the same context (I have a special decorator for storybook). This solution is less ideal, because I cannot use my package on different projects without duplicating the translation keys, but it works well enough for now.

TLDR; thanks for the quick answer, you understood my use case clearly. This feature is not a technical blocker right now, rather a nice-to-have for the future. I use a single project for all my applications as a workaround.

[stepan662]

Ok, thanks for confirming. I'll leave this issue open and we will see if there will be more demand for the feature to move it higher in priorities. Currently we have a lot of other features which have higher priority.

[weiner]

Hello,

I’m running into what looks like the same problem.

Scenario
Shared components (Header, Footer, etc.) live in Project A in Tolgee.
Each component is wrapped in its own TolgeeProvider (namespaced, lazy-loaded).

Each host application has its own Project B,C,D... in Tolgee for app-specific strings, also wrapped in a TolgeeProvider.

Problem
When both sets of providers are present on one page, only one TolgeeProvider—apparently the last one mounted—supports in-context translation.
Strings from the other providers render correctly but don’t show the in context edit overlay.

I am happy to support the problem resolution, let me know how I can help.

[jvruss]

#3461 I think it is the same problem