You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The client should load translations from the Java backend. This should happen:
When the client / I18n initializes, loading translations for the initially detected language
When the user changes the language, loading translations for the newly selected language
The backend should provide either a request handler, or a Hilla endpoint, for loading translations for a specific language. That handler would return the contents of the language specific properties file from the translations resource bundle already used by Flow apps. If there are no translations for the requested language, the backend should return a default set of translations, which should be the contents of the root resource bundle (translations.properties). The handler should somehow indicate to the client whether it was able to resolve translations for the requested language, or whether it returned the default as a fallback. Only if no fallback can be found, the handler should return an error status code, and the client should be able to show an error as well.
For now the client would load all translation strings stored in the translations resource bundle, which could include translation strings that are only used by the backend (email templates, report templates, etc.). A future enhancement could cover splitting translations, so that we only load the translations that are implicitly (automatic detection) or explicitly (developer managed) needed by the client. An alternative could be to configure filters in the backend which keys to send to the client.
The text was updated successfully, but these errors were encountered:
The client should load translations from the Java backend. This should happen:
The backend should provide either a request handler, or a Hilla endpoint, for loading translations for a specific language. That handler would return the contents of the language specific properties file from the
translations
resource bundle already used by Flow apps. If there are no translations for the requested language, the backend should return a default set of translations, which should be the contents of the root resource bundle (translations.properties
). The handler should somehow indicate to the client whether it was able to resolve translations for the requested language, or whether it returned the default as a fallback. Only if no fallback can be found, the handler should return an error status code, and the client should be able to show an error as well.For now the client would load all translation strings stored in the
translations
resource bundle, which could include translation strings that are only used by the backend (email templates, report templates, etc.). A future enhancement could cover splitting translations, so that we only load the translations that are implicitly (automatic detection) or explicitly (developer managed) needed by the client. An alternative could be to configure filters in the backend which keys to send to the client.The text was updated successfully, but these errors were encountered: