Part of #1666 (CUSTOM custom views — phase 4).
Description
A custom component renders its own static strings (button labels, headings, tooltips) that lsFusion does not provide. Give custom-view authors access to the platform's localization, two complementary ways:
- declare the strings on the form (so the server returns them already localized in the user's locale, and the component just receives the text); and/or
- resolve
{module.key} message ids and read the current locale from the custom view at runtime.
(Property captions are already localized by the platform — covered by the presentation task; this is for the author's own strings.)
FORM myForm
OBJECTS o = Order
PROPERTIES(o) number
// declare a localizable label the component will use, resolved server-side:
// e.g. exposed to the component as a localized option/value
DESIGN myForm { custom = 'OrderApp'; }
;
// runtime form (API name illustrative)
<button>{lsfusion.localize('{order.post}')}</button> // resolved in the current user localeReason
Without this, a custom UI either hardcodes one language or ships its own duplicate dictionary, diverging from the rest of the localized form. Reusing the platform's localization keeps custom components consistent and translation-ready.
Part of #1666 (CUSTOM custom views — phase 4).
Description
A custom component renders its own static strings (button labels, headings, tooltips) that lsFusion does not provide. Give custom-view authors access to the platform's localization, two complementary ways:
{module.key}message ids and read the current locale from the custom view at runtime.(Property captions are already localized by the platform — covered by the presentation task; this is for the author's own strings.)
Reason
Without this, a custom UI either hardcodes one language or ships its own duplicate dictionary, diverging from the rest of the localized form. Reusing the platform's localization keeps custom components consistent and translation-ready.