Implementation of menu navigation in the tool (Forward navigation and backward menu navigation ) using square line tool.
Multilanguage support with Noto Sans font ( language support for - all European languages, Chinese, Japanese and Korean ) using square line tool.
Finally expectation is menu navigation with Multilanguage support. That is in the run time based on the new language selection menu navigation or text in the display need to be displayed according to the language selection. (Without restarting the device new language need to be supported).
If the SquareLine studio tool does not support then a possible alternate approach in the LVGL.
What have you tried so far?
Tool selection and requirement phase of the project.
I looked at the lv_i18n tool, but its not clear to me how one would implement this with lvgl project created by SquareLine Studio in a good way. Here’s why:
Squareline studio generates the UI files, including each and every label’s text. So if one would want to use lv_i18n, every label text would have to be properly marked every time the UI is generated.
Besides, if you were to change the .yml file with the translations, the translations do not show up in the editor.
Considering this, the only option I see for properly setting the text labels is running custom code on startup that sets every text label to the selected language via lv_i18n. And then when a “change language” setting is changed, every single label in the UI would again have to be edited.
How else could changing language via LVGL generated with SquareLine Studio be done?
So glad to see this question, which I similarly had thought about and got scared of… You are absolutely correct, a monstrous function to apply all label text is the simple way to go.
Otherwise you could maybe hook into lvgl and upon screen loading you could repopulate text in the current language. Then to change language you simple change the screen or cause a screen reload.
Looking at the code generated, there is a nice init method for each screen which you could probably quickly do a find and replace on lv_label_set_text and equivalent methods, to instead use an i18n aware method (doing the gettext equivalent). The tricky bit as I see it is doing the pluralisation, because only the developer is going to know what value applies to each label.
[I tried to follow the link on lv-i18n readme, but this was closest i found with a plural example of “few” Unicode Locale Data Markup Language (LDML) ]
@kisvegabor is there a suitable way to hook into lvgl?
So back then they expected to release some sort of multi language functionality in Q4 of 2022, which makes me think this is in active development. Anyway I suppose the workaround there still stands, which is to set the labels after initialization to make them use the i18n method…
We very busy with fixing bugs and adding some other features so the i18n feature was shifted a little bit.
We have already discussed it and it we can implement it in two steps:
Add just a check box next to each text property field, like “To be translated”. If it’s checked SLS will export prefixed texts, E.g. _("text") It’s very easy to do and at least you will be able to use the lv_i18n tool
Add a new panel where you can add new languages, translations, etc, right in SLS.
So in the next release we can add 1). Do you think it will be good workaround until 2) is added?
Thanks for the fast response.
Yes, I think the first option would be a good workaround. So long as all label texts are kept consistently in the default language of the program, it should work quite well!
Perhaps, if it is not too much effort, add some sort of toggle in the project settings of SLS where the user can set all (newly created) labels to have this checkbox enabled by default.