Translate UI Schema elements #1966
Conversation
'Group', 'Category' and 'Label' UI Schema elements are now translatable via bindings. 'mapStateToLayoutProps' is enhanced to check for 'label' or 'i18n' attributes within the UI Schema element. If that's the case the translator will be invoked and the label handed over which is then used by the group renderers. The categorization renderers access the new utility 'deriveLabelForUISchemaElement' to translate the labels of their categories. This is done within the respective renderer code. For labels a new `mapStateToLabelProps` mapper is added which provides access to a 'text' property. Corresponding bindings are added to all renderer sets and used by the respective renderers. Also improves some typings in core and streamlines prop handling in the React bindings.
| const t = getTranslator()(state); | ||
| const i18nKeyPrefix = getI18nKeyPrefixBySchema(undefined, uischema); | ||
| const i18nKey = i18nKeyPrefix ? `${i18nKeyPrefix}.text` : text ?? ''; | ||
| const i18nText = t(i18nKey, text, { uischema }); |
There was a problem hiding this comment.
In case there is no i18nKeyPrefix determined in line 1097, it seems that text is effectively used as the first and second parameter here. Thus, the text would be used as an i18n key (assigned in line 1098), right? Is that on purpose. It seems to me that this could lead to unexpected behavior: E.g. There is a plain text that should be shown. By chance it matches any i18n key => The translation of this key is shown.
Or am I missing something?
There was a problem hiding this comment.
Yes that's on purpose. We do the same for error messages.
I don't know if there is a better solution, do you have something in mind? The idea is that this allows users to specify their i18n keys directly within the label if they want to.
There was a problem hiding this comment.
Okay that makes sense. Unfortunately, I cannot think of a better solution that allows providing the i18n key in a similarly simple fashion.
I guess the collision risk is reasonably low as long as users use typical formats for such keys. We can leave it like this, I just wanted to clarify :)
There was a problem hiding this comment.
There's one approach I can think of: If the label's value should be resolved to a translation, it could be marked as a variable. E.g. like one of these:
%mykey%${mykey}
This allows to specify the key inline in the label prop and still makes it explicit that this should be resolved.
There was a problem hiding this comment.
In theory these could also be collisions ;)
There was a problem hiding this comment.
I know but it makes it less likely and it is explicit that a resolvement is expected.
But I'm also fine with leaving it as is as the collision risk should be very low for reasonable users ;)
Hi, |
'Group', 'Category' and 'Label' UI Schema elements are now translatable via bindings.
'mapStateToLayoutProps' is enhanced to check for 'label' or 'i18n' attributes within the
UI Schema element. If that's the case the translator will be invoked and the label handed
over which is then used by the group renderers.
The categorization renderers access the new utility 'deriveLabelForUISchemaElement' to
translate the labels of their categories. This is done within the respective renderer
code.
For labels a new
mapStateToLabelPropsmapper is added which provides access to a 'text'property. Corresponding bindings are added to all renderer sets and used by the
respective renderers.
Also improves some typings in core and streamlines prop handling in the React bindings.