i18n: Namespacing prüfen und implementieren

[deleonio]

Zur Zeit wird kein Namespacing verwendet, was zu Problemen führen könnte, wenn es mehrere aktive Anwendungen auf einer Seite gibt, die i18next verwenden.

Prüfen, ob es hier Sinn Ergeben würde, das i18next Namspacing-Feature zu verwenden, und ggf. implementieren.

[deleonio]

@laske185 das Ticket ist für die BFIT sehr interessant!

[Chrisdo82]

@deleonio wir verwenden auch i18next und bekommen seit dem Update auf 1.7.4 den Fehler: 'TypeError: Cannot redefine property: I18n'.

Hast du einen schnellen Workaround für uns, womit wir diesen Fehler umgehen können, damit wir nicht auf eine alte Version zurückrollen oder auf den Fix warten müssen?

[deleonio]

Hallo @Chrisdo82,

Ich habe das Ticket hochpriorisiert. @laske185 kannst du bitte zeitnah danach schauen?

Danke

[laske185]

Hallo @Chrisdo82,

da KoliBri auch i18next nutzt, kann es nun vorkommen, dass i18next bereits durch uns initialisiert ist.

In dem Fall dürft ihr nicht auch das init() aufrufen.

Vermutlich müsstet ihr es analog machen, wie wir es in KoliBri umgesetzt haben:

import i18next from 'i18next';

const init = () => {
  if (!i18next.isInitialized) {
    await i18next.init({
      ns: [I18nextService.namespace],
      lng: "de",
    });
  } else {
    await i18next.loadNamespaces(I18nextService.namespace);
  }
  i18next.addResourceBundle(lng, I18nextService.namespace, translationMap, true);
}

Mit dem PullRequests nutzt KoliBri dann nicht mehr den Standard-namespace „translations“, sondern seinen eigenen mit dem Namen „KoliBri“. Die Änderung wird in Version 1.7.x und 2.0 sein.

[Chrisdo82]

Danke, wann kann ich denn mit dem nächsten Release in dem das drin sein wird rechnen?

[nefarius4schmu]

Hallo @laske185 ,
der Fix scheint die Ursache des Fehlers, welchen schon @Chrisdo82 beschrieben hat, nicht zu lösen.
im BFIT Projekt haben wir mit der letzten Version (1.7.6-RC2) das Problem unverändert reproduzieren können. Der o.g. Fix wurde für den Test auch im Projekt implementiert.

Ein Debugging hat gezeigt, dass der Konflikt an folgender Stelle in der core/index.ts entsteht:

if (STORE.I18n === undefined) {
  const i18n = await I18nextService.createInstance(options?.translation?.name ?? 'de', options?.translations);
  
  // Throws "TypeError: Cannot redefine property: I18n"
  Object.defineProperty(STORE, 'I18n', {
    value: i18n,
    writable: false,
  });
}

Nach der Ausführung der Methode I18nextService.createInstance ist die Property STORE.I18n bereits gesetzt ist. Folglich tritt der Fehler dann immer auf, "wenn" dieser Loop ausgeführt wird.

Wir führen intern weitere Untersuchungen durch, ob das Problem vielleicht auch anderweitig umgangen werden kann.

[Chrisdo82]

Noch als kleine Randnotiz: bei uns tritt der Fehler den ich oben beschrieben habe nur auf, wenn ich den Cache nicht deaktiviere. Sobald der Cache aber deaktiviert wurde, kann man den Fehler nicht mehr nachstellen.

[Chrisdo82]

@nefarius4schmu habt ihr denn rausgefunden ob das Problem umgangen werden kann?

[deleonio]

Release 1.7.6 ist draußen.

[nefarius4schmu]

Hallo zusammen ,
zumindest durch Anpassungen in unserer App lässt sich das Problem scheinbar nicht umgehen.
1.7.6 bringt da auch keine Verbesserung.

Ich konnte das Problem testweise umgehen, indem ich lokal die Sourcen der KoliBri-Library angepasst und die globale Variable "I18n" in "I18nextService" umbenannt habe, sodass sie folglich unter STORE.I18nextService erreichbar ist.
Also:

Object.defineProperty(STORE, 'I18nextService', {
    value: i18n,
    writable: false,
});

(und entsprechend dazugehörige Änderungen im Code)

Danach trat der Fehler nicht mehr auf. Weder im Build oder mit Cache enabled/disabled.
Natürlich konnte ich jetzt eventuelle Nebeneffekte nicht testen, aber es sieht jetzt erstmal vielversprechend aus.

@deleonio
Gibt es Gründe warum die Variable "I18n" heißen muss bzw. könnt ihr den Vorschlag bitte mal evaluieren?

[deleonio]

Vielen Dank für den Input @nefarius4schmu, wir nehmen das mit. Zudem überlegen wir i18next zu einer peerDep zu machen.

[deleonio]

Weiterführende Aktivitäten besprechen.

[laske185]

In neuem Ticket weiterführen. Namespaces sind nicht das Problem.