SiTranslatePipe shouldn't translate group keys

[spliffone]

Update

Based on the discussion below we will introduce a marker for keys that should not be translated, similar to bypassSecurity... by Angular:

const translatable = bypassTranslation('NOT_A_KEY')

I assume that either prefixing the string or just having an object should work. When implementing please evaluate the approach of bypassSecurity....

Prerequisites

• I have read the Contributing Guidelines.
• I have not leaked any internal/restricted information like screenshots, videos, code snippets, links etc.

Affected component

No response

Summary

Currently the SiTranslatePipe return objects if the user pass a group key which result in a unattended display of the value [object Object].

Instead we should return the passed key if the translation result is an object. Since we don't have the use case in our library to translate and display groups.

Example:

de.json:

{
  "LANGUAGE": {
    "EN": "English",
    "EL": "Greek",
    "DE": "Deutsch",
    "FR": "Français"
  }
}

component.html:

<h1>{{ 'LANGUAGE' | translate }}</h1>

Version

No response

Steps to reproduce

Open example:

https://element.siemens.io/element-examples/#/viewer/editor?theme=light&locale=de&t=%3Ch4%3EVariant%20Light%3C%2Fh4%3E%0A%3Cdiv%20class%3D%22px-4%22%3E%0A%20%20%3Csi-filter-bar%20%5Bfilters%5D%3D%22%5B%20%20%20%20%7B%0A%20%20%20%20%20%20filterName%3A%20'temperature'%2C%0A%20%20%20%20%20%20title%3A%20'LANGUAGE'%2C%0A%20%20%20%20%20%20description%3A%20'30%C2%B0'%2C%0A%20%20%20%20%20%20status%3A%20'default'%0A%20%20%20%20%7D%2C%5D%22%20(filtersChange)%3D%22logEvent(%24event)%22%20%2F%3E%0A%3C%2Fdiv%3E%0A&e=si-filter-bar%2Fsi-filter-bar

Code reproduction example

https://element.siemens.io/element-examples/#/viewer/editor?theme=light&locale=de&t=%3Ch4%3EVariant%20Light%3C%2Fh4%3E%0A%3Cdiv%20class%3D%22px-4%22%3E%0A%20%20%3Csi-filter-bar%20%5Bfilters%5D%3D%22%5B%20%20%20%20%7B%0A%20%20%20%20%20%20filterName%3A%20'temperature'%2C%0A%20%20%20%20%20%20title%3A%20'LANGUAGE'%2C%0A%20%20%20%20%20%20description%3A%20'30%C2%B0'%2C%0A%20%20%20%20%20%20status%3A%20'default'%0A%20%20%20%20%7D%2C%5D%22%20(filtersChange)%3D%22logEvent(%24event)%22%20%2F%3E%0A%3C%2Fdiv%3E%0A&e=si-filter-bar%2Fsi-filter-bar

What is the current bug behavior

• group keys shouldn't get translated via pipe
• never return objects via pipe

What is the expected correct behavior

• in case the translation service returns an object the pipe should return the key

[timowolf]

@spike-rabbit We do not remember if this was introduced by intention? May you verify if we can remove the group level translation?

[spike-rabbit]

The ngx-translate pipe has the same behavior. Please explain why we should diverge. I don't see where this is a problem.

[spliffone]

The ngx-translate pipe has the same behavior. Please explain why we should diverge. I don't see where this is a problem.

We have a problem everywhere were apps provide a TranslateableString input which value is derived from an user input.
So far we never used the SiTranslatePipe to get all translations under a group since it is anyway challenging to deal with the result. Further the pipe is used internally so we can diverge from the ngx-translate logic.

[spike-rabbit]

But I guess in that case they generally don't want translation at all right? So I think as you suggested in the issue, the solution would be to just provide the SiNoTranslateService?

--> so we should provide something like disableAutoTranslation() maybe also as a directive so it can be applied to a component?

[dr-itz]

But I guess in that case they generally don't want translation at all right? So I think as you suggested in the issue, the solution would be to just provide the SiNoTranslateService?

--> so we should provide something like disableAutoTranslation() maybe also as a directive so it can be applied to a component?

but that doesn't work as probably most of the component should still be translated, just not the user input. The problem is components that have content that is either component provided TranslatableString that should be translated and input by the user that should not. Looks more like a component design issue to me. Should look at real component problems

[spike-rabbit]

This is coming from the filter-bar. I guess there it is actually hard to predict whether we have user text or application keys as both could be valid use cases.

@dr-itz That the component wants to keep translation in general is a valid point though.

Other options I see:

• dedicated inputs for not translatable labels for the filter-bar
• similar approach to angular security bypass const translatable = bypassTranslation('NO_A_KEY'), maybe also as a pipe

[dr-itz]

* similar approach to angular security bypass `const translatable = bypassTranslation('NO_A_KEY')`, maybe also as a pipe

I think having this is a nice addition in any case

[spike-rabbit]

Thx a lot. I updated the issue description.