Include translations in lens

[timakro]

Currently some user-facing messages are configured in the lens options, e.g.:

            "text": "Alle Hinzufügen"

I feel like it would make sense to include these translations in lens and configure only the language (english or german) in the lens options.

Advantages of this approach would be:

• Reduces the amount of lens options
• Gets rid of duplicate translations across multiple projects that use lens

Possible issues:

• Might not be feasible for the majority of user-facing messages as many seem to be project specific. For example the chart hint texts seem to be mostly specific to CCP? Correct me if I'm wrong.

---

If we want to move forward with this approach here is my suggestion how to implement it.

I've looked into localization libraries and didn't find anything I liked. Some are no longer maintained (sveltekit-i18n, typesafe-i18n) and others pretty intrusive (Paraglide JS). I would propose an extremely simple approach of having a file german.json:

{
    "Add all": "Alle Hinzufügen",
    "Processing...": "Lädt...",
    "Results": "Ergebnisse"
}

And a function translate:

import germanTranslations from "../translations/german.json";

export function translate(englishText: keyof typeof germanTranslations): string {
    const language = get(lensOptions).language;

    switch (language) {
        case "english":
            return englishText;
        case "german":
            return germanTranslations[englishText];
    }
}

Then use it like that:

<button part="add-all-options-button" on:click={selectAllOptions}>
    {translate("Add all")}
</button>

Typescript will show an error if you are trying to translate a string that is not defined in the translations JSON file.

[patrickskowronekdkfz]

I think having a translate option is a good move forward. A library always adds dependencies, which are in my opinion not always necessary. I like a minimal implementation and have some thoughts about your suggestions.

I would not add another json config file. I would put it in the options. Something like:

{ "lang": "ger", "labels": [{"label": "add_all", "text": "Alle hinzufügen"]}

The translate function would then look for the default or selected language. The usage of the function is ok, I would rather use a label instead of the text directly.

Also some other thoughts. The lens team did think about this from the start and had a German and English label in the catalogue, do we want to readd this?

[patrickskowronekdkfz]

Looking into the future of lens, each project will focus on different delivery of data, therefore the messages to the user might change. We would need to override then the default or allow injecting different messages into the service.

Let's go with the text, how would we support developers. Let's say someone wants to build a German version of a UI and misses one label. I think mixing languages is bad. I also think we should keep core library as lightweight as possible. I would't add a whole dictionary for all text's.

We want to switch to English in the CCP-Explorer or support multi language.

Maybe we find a better idea.

[timakro]

My main motivation for this proposal was #196 so let's take that as an example. When continuing with the current approach we would have to add something like this to the options.json file for all projects that use lens:

{
    "connectionErrorMessage": "Fehler beim Bearbeiten der Anfrage",
    "beamErrorMessage": "Fehler von Beam erhalten",
    "negoatitorErrorMessage": "Die Antwort vom Negotiator ist fehlerhaft",
}

And if we add a new error message all projects need to add it to their options.json. We are placing an enormous amount of upkeep on our users and on ourselves because every changes like this becomes a breaking change.

[torbrenner]

I think, we would need some kind tradeoff between both, keeping the library lightweight and not making each change to a breaking change.
I personally like the idea of having separate translation files per language, because that would for the future allow us to just give 1 file to a translator and let that person translate it (in case at one point we would need to translate to another language we all don't know that good). I think that is also the reasoning behind the approaches of the i18n implementation.
Could we make it possible, that we source from two translation locations, the first being the default one in the library and the second being provided by the end application? If this would be possible, we could avoid breaking changes by providing default translations for german and english for all new texts that we add, while the functionality of translation would also be applicable to custom texts added by the end application? So the idea would be that lens "german.json" would be merged with project "german.json" and the projects german.json would always have higher priority.

[timakro]

I agree it would be useful for applications to be able to use the translation functionality as well, considering that we may want to provide multiple languages in some of the applications in the future. I like the idea of @torbrenner to provide default translations in lens for some texts and allow applications to add their own translations. If we use short labels (e.g. add_all) like @patrickskowronekdkfz suggested, applications could also use this system not only to add new translations but also to overwrite texts in lens with their own custom text. We can add something like this to the lens options:

"texts": {
  // Applications can add their own translations, maybe prefix them with the name of the project to avoid conflicts.
  "ccp-welcome": { "en": "Welcome to the CCP explorer!", "de": "Willkommen beim CPP Explorer!" },
  // Applications can overwrite texts in lens (this is a stupid example)
  "add_all": { "en": "Add all of the options", "de": "Alle Optionen hinzufügen" },
}

This would be merged with translations that are included in lens, while texts from applications should have higher priority.

Then we would have a function that can be called like translate("add_all") to get the translated text in the currently active language. We can export that functions so applications can use it.

It would be nice if we could make that function reactive when used with Svelte, such that when the language is changed texts automatically update without a page reload. I don't know if it's possible and even if it's possible it may be a tradeoff where it makes things so complex that we better avoid it. Also considering that we want to support applications that use e.g. React instead of Svelte this may be a bad idea.

[patrickskowronekdkfz]

@timakro I think we are on the right track. I think we should think about a mvp. Let's start for version 0.5 with error toast and some buttons and then see if the projects like it or not. Then we can extend it or change it.

As @torbrenner suggested project should be looked at first and the lib should do the rest if present. About the options structure, for the first release it is ok. When we think into the future, where other languages would arise this structure would create bad schema's.

I'm looking forward to the first implementation.

Cheers Patrick

[timakro]

Translations are implemented: https://github.com/samply/lens/blob/develop/book/src/guide/translations.md