-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design and provide some I18N for design. #637
Comments
Originally by @jdahlstrom I18n support for the core framework is something that's been requested for years and was originally on the 7.0 wishlist (#5313). It's obviously a very complex issue. |
Related FW issue: vaadin/framework#1161 |
Hello there! It looks like this issue hasn't progressed lately. There are so many issues that we just can't deal them all within a reasonable timeframe. There are a few things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):
Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too! |
The issue was automatically closed due to inactivity. If you found some new details please comment on the issue so that maintainers can re-open it. |
Still an issue with Vaadin 14 and the Designer: vaadin/flow#3906 |
See also vaadin/flow#3906 |
Originally by @denis-anisimov
At the moment it's not possible to create design which is targeted to be used for several locales.
Any string is set into HTML as is.
Core framework doesn't allow to embed any I18N, so we need some support from core.
I would suggest:
F.e. an attribute for HTML which means that Text node is not a vlaue but a key which should be used to retrieve real value from a provider:
LBL_Title
or use directly an element instead of Text node
LBL_TitleProvider should be used to get real values on deserialization.
Serialization would be tricky since component doesn't contain the key which has been used to set property value.
It requires some thinking.
On the designer side we can provide a default Provider which uses properties to store pairs "key=value" (Java property bundles).
By default: no providers , all values are stored as is.
User should be able to implement it's own provider to plug it's own way to fetch values for the key.
Imported from https://dev.vaadin.com/ issue #18844
The text was updated successfully, but these errors were encountered: