I am writing to request a more comprehensive guide regarding the implementation of LVGL multilanguage support in conjunction with SquareLine Studio (SLS). While the existing guides provide a foundation, they lack crucial technical details and sample code, hindering the smooth integration of this feature into our projects.
Specifically, the current documentation on lvgl/lv_i18n: Internationalization (i18n) for LVGL, available on the LVGL GitHub repository, mentions functions such as lv_i18n_init and lv_i18n_set_locale. However, upon exporting the code from SquareLine Studio, we noticed that these functions are missing. This discrepancy has led to confusion and challenges in properly configuring multilanguage support within our applications.
To address this issue effectively, it would greatly benefit the LVGL community and SquareLine Studio users if the multilanguage app guide included detailed sample code illustrating the proper implementation of LVGL multilanguage features. By providing practical examples, developers will gain a clearer understanding of the required steps and how to integrate multilanguage support seamlessly into their projects.
Furthermore, it would be highly advantageous if SquareLine Studio could provide a sample project on GitHub that demonstrates the utilization of i18n (internationalization) with SquareLine Studio. This sample project would serve as a valuable resource, allowing developers to reference and learn from a comprehensive, real-world example.
By enhancing the existing documentation with more technical details, sample code, and a sample project, SquareLine Studio can significantly improve the developer experience and streamline the implementation of LVGL multilanguage support.
Thank you for considering this feature request. We look forward to the continued growth and improvement of SquareLine Studio’s development tools.
I have successfully implemented the Squareline Studio Multilanguage feature in my project, utilizing lv_i18n scripts and a Python environment.
In the coming one or two days, I intend to compose a comprehensive blog post outlining the detailed steps involved in this implementation. Once the blog post is complete, I will provide a link within this forum post for convenient access to the detailed information.
Hi, this is really great to hear. I am almost at the point of multi-language implementation on my project as well, but I think I will hold off on working on that until your blog is complete: I think i18n is really quite complicated and I am a bit afraid of sinking too much time into it.
I was able to get lv_i18n working with a few languages with a few labels in my project. What got me in Windows command prompt is that you must use double quotes like
@christine@kisvegabor What is the proper way we are supposed to update all the text when the language is changed on the fly?
There isn’t any problem if the language is set prior to calling ui_init(). However, if it is changed after, say in a settings menu on the screen, lv_i18n expects that we call lv_label_set_text to update them. I have over 500 of these calls from my SDS project. Worst case is that I could reboot the machine which isn’t great.
Here is my code snippet to update all the text in LVGL on the fly without rebooting.
void ui_events_language_change(void)
{
if (locale != NULL) {
// Set the active locale using lv_i18n API
int result = lv_i18n_set_locale(locale);
if (result == 0) {
printf("Set locale success");
} else {
printf("Set locale failed");
}
}
// refresh all LVGL multilanguage label
refresh_lv_i18n_label_text();
}
void refresh_lv_i18n_label_text(void)
{
// lv_label_set_text() every multilingual label in your project, I have many lines in my actual code
lv_label_set_text(ui_label, _("Countdown"));
lv_label_set_text(ui_label, _("Set timer"));
}
This is one way to do it since LVGL does not have any kind of language set like in v5 of LVGL. I may end up doing the same thing unless I decide to reboot the device. This method is a bit messy with SDS because you have to remember to add the lv_label_set_text anytime you use To be translated. This could turn into an easy mistake making it out to the end user.
I think a better approach would be for SDS to create a function for us to call when the language has changed. Internally this function would call each screen c file and set whatever text is To be translated for consistency with SDS’s structure. I image this wouldn’t take much time for SDS to implement either.
We would only be responsible for our own lv_label_set_text which reside outside of SDS’s generated code.
FYI, there is a bug if you install lv_i18n via npm i lv_i18n -g, and you have escape characters, such as a newline in your SDS text. You can install the latest master branch to address this.