Providing module specific L10n when creating module for client

Client
1

Question on behalf of @sebastian-long-chasm:

Hi A12-Client Team. I was currently wondering, if and how - when creating a module for bap client - i can provide module specific L10n.
For example there are the default Translations in BAP Client set like this:

export const DEFAULT_TRANSLATIONS: LocalizationTreeMap = { 
  en: en_EN,
  de: de_DE
}
….
	const localizer = createApplicationLocalizer(locale, documentModelMap, dataFormats, DEFAULT_TRANSLATIONS);

So now, I have my module:

const module = (): Module => ({
    id: "MyModule",
    views: () => viewComponentProvider
})

which does not seem to have a configuration / member for it’s own translations
so Currently, the only thing I see, is to extend the surrounding client code with something like this:

export const DEFAULT_TRANSLATIONS: LocalizationTreeMap = {
	en: {
		...en_US,
		...en_US_Of_My_Module
	},
	de: {
		...de_DE,
		...de_DE_Of_My_Module
	}
};

Are there any other ways / suggestions / ideas to solve this?

If not, I would like to propose to create an extension point for module specific l10n

2

Hi,

I’m not 100% sure that I fully understand what you’re doing at the moment. That’s why I want to point out some general ideas at the beginning.

The LocalizationTreeMap that you can pass when creating the localizer function should only be used for the customization of the localization functionality that we already bring with the client and other libraries, e.g. form/overview/tree engine etc.
Example you don’t like the texts of the modal dialogs for dirty handling? Overwrite those with your own texts and pass them as a LocalizationTreeMap.

If, however, you want to localize your own UI fragments and you want to use A12’s localizer for this, you should create and pass localizable objects to the localizer that already contain the proper texts as defaults. Then you don’t need to pass or extend this map at all.

In short, this map is only meant for overriding built-in localization texts.

Regarding modules:
You can always extend the Module interface and add more properties to your application-specific modules. In this case, you could add a property that refers to the localization resources for the module.

Your code - that ultimately creates the localizer function - can then use the Module API (i.e. the ModuleRegistry) to collect all of your active modules and their localization resources, and pass them to the localizer factory call in the way that you need.
It does not have to be a LocalizationTreeMap. The defaultLocalizerFactory also allows you to pass a TranslationFinder function instead of a LocalizationTreeMap (see defaultLocalizerFactory (TypeScript API on getA12.com)).

Still, I would like to first ask why your modules need to have this possibility. Do all of them need to overwrite built-in texts?
If so, what happens when different modules want to overwrite the same text (i.e. the same localizable key)?
Who wins? This cannot be imlemented in the client. However, it could be implemented in a TranslationFinder function.

If you only want to provide those texts for the localizables that your module code creates, then please see my point in the beginning.