[Feature Request][localize] Allow to override translations

[igomezal]

What do you think of the possibility of overriding the namespaces defined by a component so you can use custom translations in different parts of an application or page?

So if I do the following:

import { localize } from '@lion/localize';

localize.loadNamespace({
 'my-component': locale => {
   switch(locale) {
        case 'en': return import('./assets/custom-translations/es.js',
   }
 }
});

It will override the namespace I previously defined in my-component.

I know that if I load this namespace before I instantiate my-component it will load with my custom translation and not with the one defined in my component, but It could be good to be able to override it again in other part of application because you need to show a different set of translations.

Or just be able to delete this namespace and load it again, right now it is only possible to clear all the namespaces and load all the namespaces, not just one namespace.

What do you think about it?

[jorenbroekema]

Maybe I'm misunderstanding, but your example seems to assume a hard coupling between the component tag name and the localize namespace, but I don't think this hard coupling exists.

E.g. if you use LocalizeMixin to couple your web component to a localize namespace, you are free to choose the name of your namespace, it doesn't have to be the same as your component's tag name.

I think there are in general some missing features in localize though:

Override the namespace's translations resolutions after the namespace has already been loaded

localize.loadNamespace({
  'my-component': locale => {
    switch(locale) {
      case 'en': return import('./assets/custom-translations/en.js',
    }
  }
}, true); // `override` true | false, false by default

If the 'my-component' namespace already exists, I believe it just returns your the existing loader from the cache, instead of overriding the existing one? https://github.com/ing-bank/lion/blob/master/packages/localize/src/LocalizeManager.js#L100 So we should at least allow an override option which ignores cache, so we can bust it and load an override namespace. I think that suits your use case @igomezal ?

Edit the localize namespace translations for specific language

localize.editNamespace('my-component', 'en-GB', import('./assets/custom-translations/en.js'));

Sometimes default translations are great, your design system provides them, but it might be nice if your users can override some translations for some locales, e.g. if a country-specific program decides they need a different field label. We see this pretty often in ING that the tone of voice differs, sometimes for good reasons.

If the custom translation override is smart it would do something like:

import en from '/path/to/design/system/default/translations/en.js

export default {
  ...en,
  inputAmountLabel: 'Stackz', // the override
}

then that should work pretty well.

Change the localize namespace for a single component instance level

const myEl = document.createElement('my-element');
localize.changeNamespace(myEl, namespaceObj);

E.g. when you have custom translations for a special instance of a web component that deviates from the default one. Maybe this use case is a little extreme, I can't really think of realistic examples but maybe someone else can.

[igomezal]

The first feature is what I wanted to explain in my comment, and with a new flag like you did, it would be possible to implement it, if you don't mind I can to try create a PR with this new feature.

About the two other features you mentioned, I think they could also be useful.

And about the last one, I can think of a possible use case where an application is used by a common user then it shows translations for that kind of user and then when a user with more privileges or with a different kind of expertise then the translations for that user could be more complete or precise (like when you show errors).

Or even with two different flows but with this flows use the same web components, in this case it could also be possible to apply this third feature you mentioned.

It's true that it is not a common use case and this third feature would not be used as much as the other two.

[igomezal]

So I just created a pull request #743

This allows the user to override the translations of any namespace.

[jorenbroekema]

Hey @igomezal been a while since we updated you. LocalizeManager is now going to get a pretty major refactor and is one of the main things we wanna do before lion v1 release. This issue will be used as a reference, and we'll take your PR into account as well. Closing this for now as an enhancement with votes needed. Feel free to 👍 it to vote

[jorenbroekema]

Another common feature request is to allow html strings in translations. We should probably support it, and render such strings with lit-html. I I believe this will mean that we need to do something under the hood to parse and sanitise such strings? Probably better that we accept TemplateResult | non html string then, and not HTML string itself.

Maybe like so:
en.js

import { html } from '@lion/core';

export default {
  error: {
    FooValidator: html`<lion-notificiation error>Wrong!</lion-notification`,
  }
}

[jorenbroekema]

Started establishing requirements for new localize and potentially a POC with @lit/localize. See #1309

[tblaisot]

It will be nice to be able to remove some locales too to reduce bundle size when your application is not needing a locale.
overriding it is not enough because bundle will already include all the locale files.
I would like to be able to choose the locales to include via specific imports at the app level