timezones with GMT offset. Support for translations?

[LeoZanella]

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]

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:

• Add translation #459
• WLED on another languages #2165

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]

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]

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:

[blazoncek]

@Sojourneer please work on 0_15 branch.

[Sojourneer]

@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]

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]

@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]

@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]

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