Multi-language support in PIE and pie-cookie-banner

[fernandofranca]

As a follow-up for the DSW-1195 spike (already published on Confluence), this discussion was created to gather opinions and ideas about how to handle the translation of the pie-cookie-banner component.

These are some of the themes I believe might be worth discussing:

• Considering the limitations of the @lit/localize library, what would be the best way to handle the translation of the pie-cookie-banner component?
• Do we agree with the idea of bundling all translation data within the package?
• Should we have a version of the cookie banner that doesn't bundle any translation data? The consumer would be required to pass the data as a prop.
• Should the cookie banner be responsible for locale detection and switching the content automatically? For context, CW handles this at the application level.

[jamieomaguire]

Thanks for the write up @fernandofranca, it makes a lot of sense.

I did wonder, could one alternate approach (basically your alternate flexible suggestion) be to store the translations in a separate package/export and have the consumer import it and pass down the appropriate translations object to the cookie banner at runtime? We still guarantee the copy is consistent but add some decoupling which could help with bundle size performance I think.

Something like:

import { en, de } from '@justeattakeaway/pie-cookie-banner-translations'; // OR something like '@justeattakeaway/pie-cookie-banner/translations'
import { PieCookieBanner } from '@justeattakeaway/pie-cookie-banner/react';

// arbitrary example of choosing a translation
const cookieTranslations = applicationLocale === 'de' ? de : en; 

<PieCookieBanner copy={cookieTranslations}></PieCookieBanner>

In any case, your solution seems excellent. Great stuff! 🎉

[ashleynolan]

I think this could make sense - just to add to this, could you just publish this as part of the same cookie banner package and have a different entry point potentially for the translations? (just to save on managing this across 2 different packages)

[jamieomaguire]

Yeah for sure. Fernando mentions an approach along the same lines as this in his write-up.

[fernandofranca]

Also looks good to me.

[kevinrodrigues]

@fernandofranca nice one, i have read through it and it LGTM. I had one question:

Regarding the configureLocalization and the error you have could we potentially pass in the configureLocalization helper from lit to a generic method that would then be extended in the constructor which then in turn is used to export the component? I know you stated "runtime" output mode also seems to be more fit to be handled at application level rather than component level but was just curious.

e.g

function configureLocale(locale) {
  const { setLocale } = configureLocalization({
      sourceLocale,
      targetLocales,
      loadLocale: async (locale) => availableLocales[locale],
  });
}

function initLocaleComponent(WrappedComponent) {
  return class extends WrappedComponent {
    constructor() {
      super();
      configureLocale(this.locale);
    }
  };
}

// Then here at the end which is where i think the error may not appear although did not test..
export default initLocaleComponent(MyComponent);

[fernandofranca]

That's a nice approach, though the problem lies not in how we configure the translation.

The configureLocalization method itself can only be called once, calling it a second time doesn't work and throws an error.