search

Aircoookie / WLED

Control WS2812B and many more types of digital RGB LEDs with an ESP8266 or ESP32 over WiFi!
https://kno.wled.ge
MIT License
14.94k stars 3.23k forks source link

timezones with GMT offset. Support for translations? #3180

Open LeoZanella opened 1 year ago

LeoZanella commented 1 year ago

Can we have a separate file for translations? I think this would make it better to add languages. I'm trying to translate it to Portuguese and it is being really hard. About the timezones, wouldn't it be better if, instead of zones name, we have the increments (-3 for Brazil). I have to configure it and a not good way to get the time right for my zone.

softhack007 commented 1 year ago

Hi, I think that the timezone name plus increment is a good idea, and will be simple to implement; for example we could show "[GMT+1] CET/CEST" to indicate the offset from GMT. Just that we would not list all the capitals in that time zone, to avoid inflating firmware size unnecessarily.

https://github.com/Aircoookie/WLED/blob/999bec19f1bf37b344177a9aeffc752c5f4ae472/wled00/data/settings_time.htm#L161-L186

About translation support .... well that's more complicated. WLED is missing the source code infrastructure to support translations, and some texts are directly coded in .cpp files and not found in the web sources inside data/.

You might be able to do a translation for yourself right now, but we cannot include that into the main WLED repo afterwards. See also:

Also as WLED is developing further, we'd need regular translation contributors who would take care of translating new things with each release. However the first problem is to build a source code infrastructure for supporting translations, which is a complicated development task.

softhack007 commented 1 year ago

I'm putting the "[GMT+1] CET/CEST" idea on the list for 0.15.0, as it seems easy to implement. Another option would be "CET(+1) / CEST(+2)" to also clarify the daylight savings time abbreviation.

For translations - sorry no news, we still have no concept/design to support that request.

Sojourneer commented 1 month ago

I am working on the Internationalization piece. The flow is as follows, populating an I18N folder structure, and finally copying localized files back to wled00/data. Each step is supported by a script. This stepwise method with JSON intermediate data in files allows for manually tweaking.

1) Scope: Get list of wled00/data files from cdata.js 2) I18N: For each file, preserve into an I18N folder, and then scan each file for text and for @title attributes, outputting I18N templated files and a phrase index Now, for your target language: 3) Translate: Localize the index using google translate API 4) L12N: Apply the localized index to the templates, and copy the localized files into the wled00/data

After this, the UI node build would be used.

I'm working on step (4) now. My target language is Japanese.

Here is an extract for the translated Blue entry: image

blazoncek commented 1 month ago

@Sojourneer please work on 0_15 branch.

Sojourneer commented 4 weeks ago

@Sojourneer please work on 0_15 branch. Understood. My target is to finish for this Christmas season. November at latest, and I'll plan to move it over by then. Busy busy.

Sojourneer commented 3 weeks ago

I've finished the first round (my fork from 0.14.3 I believe, late March 2024), up to L12N and building the UI and executable (I'm on the road this week so not able to test on an actual device). Looking at the resulting HTML, I've noticed a sprinkling of dynamic generation of HTML. I'm thinking of hand editing the dynamic generation scripts to pull from hidden HTML rather than strings, which would allow use of the same translation apparatus. @blazoncek Any comments on the above?

Next step for coverage completeness would be to look at text provided from cpp files. This would require pulling from a L12N (.h or .json) file, probably structured in some way. Again the same translation apparatus could be used. I presume the changes to the mainline code would be more intrusive if not particularly deep. Personally, for things like effect names, I don't think there is much point.

blazoncek commented 3 weeks ago

@Sojourneer there are three places that provide text for UI: HTML & JS files and C++ source (in JSON response to requests). The latter are few.

As we are working on MCU that has limited resources (RAM, flash, CPU power) it would be best to limit number of I18N files to only the one required by user.

My suggestion would be to add JS code, that will load (i.e. from Github repository or from embedded flash) the localisation file and keep it in browser's local storage or cache. AFAIK getting files from Github may be problematic since there is no HTTPS support in WLED so my recommendation would be to allow user to upload localisation file to flash. I would keep English texts in sources and replace them when UI loads.

Sojourneer commented 3 weeks ago

@Sojourneer there are three places that provide text for UI: HTML & JS files and C++ source (in JSON response to requests). The latter are few.

As we are working on MCU that has limited resources (RAM, flash, CPU power) it would be best to limit number of I18N files to only the one required by user.

My suggestion would be to add JS code, that will load (i.e. from Github repository or from embedded flash) the localisation file and keep it in browser's local storage or cache. AFAIK getting files from Github may be problematic since there is no HTTPS support in WLED so my recommendation would be to allow user to upload localisation file to flash. I would keep English texts in sources and replace them when UI loads.

I think you may have misunderstood my approach, although I think I was clear in the above. I am providing for localization that is applied at build-time, not dynamically. I don't require dynamic language switching, and therefore I am not pursuing that. The resource requirements should be minimum. I'm writing up the procedure now as sketched in the above.

blazoncek commented 3 weeks ago

IMO that is unacceptable as users will most likely download official builds that will not be localised.

Sojourneer commented 3 weeks ago

IMO that is unacceptable as users will most likely download official builds that will not be localised.

Ah well, that is too bad. Maybe your translation community can be sweet-talked into taking the task of building the necessary builds. The translation itself is done through googletrans and requires only review. With current coverage, admittedly not 100%, a decent draft translation can be done in a couple of minutes.

In the meantime, I will work only on my current fork https://github.com/Sojourneer/WLED I18N.pdf

Aircoookie commented 3 weeks ago

Some years ago by now, I also put some thoughts into how to best support translations. I've arrived at the following conclusions back then as to what would likely make most sense.

There are some details left to work out like how/when to update language files on firmware update and how to translate English strings assembled on the ESP, but that is the overall idea.

Language specific binaries are a valid approach, but I don't think they would be the best fit for the project long term as they are not flexible and would balloon the plethora of different builds that are already out there even further. It would essentially only be possible to supply all possible binary variants with a build-on-demand website that lets you pick the desired features and language, which I don't think is the best user experience and also harder to maintain. Don't get me wrong, I really appreciate you looking into translations though :)

Sojourneer commented 3 weeks ago

Some years ago by now, I also put some thoughts into how to best support translations. I've arrived at the following conclusions back then as to what would likely make most sense.

  • purely in-browser JS - this won't require any extra processing on the MCU to support I18N.
  • downloading a localisation dict .json from github for the installed WLED version and desired language (HTTPS is not an issue, since the browser fetches from github, not the ESP itself). The only drawback is that internet connection is required at the time of language selection. Alternatively, the language file could be uploaded to the ESP filesystem
  • store this translation file in browser localStorage and/or ESP filesystem

There are some details left to work out like how/when to update language files on firmware update and how to translate English strings assembled on the ESP, but that is the overall idea.

Language specific binaries are a valid approach, but I don't think they would be the best fit for the project long term as they are not flexible and would balloon the plethora of different builds that are already out there even further. It would essentially only be possible to supply all possible binary variants with a build-on-demand website that lets you pick the desired features and language, which I don't think is the best user experience and also harder to maintain. Don't get me wrong, I really appreciate you looking into translations though :)

I need the Japanese translation now, so I have no choice. I'll update this post as I address the remaining fiddly bits.

Sojourneer commented 3 weeks ago

  • purely in-browser JS - this won't require any extra processing on the MCU to support I18N.

  • downloading a localisation dict .json from github for the installed WLED version and desired language (HTTPS is not an issue, since the browser fetches from github, not the ESP itself). The only drawback is that internet connection is required at the time of language selection. Alternatively, the language file could be uploaded to the ESP filesystem

  • store this translation file in browser localStorage and/or ESP filesystem

@Aircoookie After trying out on a device, and taking a closer look, I think it shouldn't be too hard applying the L12N on the browser side after doing the I18N and translation preparation along the lines I have taken so far (templatizing, moving JS strings to hidden HTML) + listing out the effects and palettes using the provided json URL for input to the translation process. This would allow for dynamic language switching. Storing master translation json on github would allow for global correction of translations which is probably a good idea.

Any suggestion on how the language to be server should be indicated, e.g. the URL, a parameter, etc. etc.?

One other question edit.htm doesn't appear to be applied to the executable. As far as I can make it out, the Webserver library's edit.htm as encoded in SPIFFSEditor.cpp is being used. Is it possible to override that, and even better, to include that in the UI build process?

Sojourneer commented 2 weeks ago

@blazoncek @Aircoookie

@Sojourneer please work on 0_15 branch. Understood. My target is to finish for this Christmas season. November at latest, and I'll plan to move it over by then. Busy busy.

FYI: I am underway with the dynamic language feature, and have gotten the translation tools and templating/localization of the HTML to work. I have made a simple python HTTPServer with .on() handlers to simulate the application enough to test the UI in a PC environment. I notice an apparent problem in GetURL of 0_15 index.js which is interfering with testing, and makes me think that branch is not yet stable + and also quite substantial. So, with apologies, I am going to move the translation work to a fresh branch of main for the meantime.

blazoncek commented 2 weeks ago

main is obsolete and will be replaced by 0_15 shortly. getURL() is there to allow running WLED behind reverse proxy.

Sojourneer commented 2 weeks ago

main is obsolete and will be replaced by 0_15 shortly. getURL() is there to allow running WLED behind reverse proxy.

I am sure you realize that I18N has a large scope and footprint in this application, and 0_15 seems even more so. It is not just an feature that can be bolted on.

getURL() accesses /index.html/json/palettes etc, and I have tried with various host/port combinations. I was not able to reverse engineer a spec for it. How well has 0_15 been tested? If it is basically stable, I have temp patched getURL for my purposes and can go forward EDIT index.js getURL() is failing as described above on http:///index.htm, but it works on "http:///" so it is Just a minor bug. I'll continue on 0_15 as recommended.