Proper Web interface (labels) translation

[Warlib1975]

Hi,

thank you for the lib. A lot of features.

Could you give some recommendations on how properly make translation/localization of the AutoConnect lib? You regularly make some significant features addition or bugs fixing and it would be good to have a way not to replace *.h files with translated labels, but override labels in the code, e.g. using ifdef.

[Hieromon]

This topic continues in the Discussions.

[Hieromon]

The standard method for localizing the label language provided by AutoConnect is as described in the documentation as follows:
How to change the label text.

What are the disadvantages of this method for you? If you can provide a specific use case, we will consider improvement measures.

[Warlib1975]

Hi. Thank you for the response. I don't understand how to make multiple languages support and switching between languages at the first Captive Portal screen manually and/or by browser language default settings.

Than you.

[Hieromon]

switching between languages at the first Captive Portal screen

It does not support the ability to switch languages while AutoConnect is running. It is determined at build time. This specification decision is based on the PR #178. (There is not enough flash to allow dynamic switching in the first place)

[Warlib1975]

In some cases flash memory limits not so expensive to solve, e.g. using ESP32 with 8/16 Mb flash memory. In the case when a product should be used in markets where the national language is a priority, but some of the customers prefer to use English as a common language, the possibility to switch between two languages is very useful. The best option will be to have the possibility to use not precompiled in the lib localization but gzip compressed file from SPIFFS.

[Hieromon]

I don't quite understand what you are saying. gzip from spiffs? What part of the AutoConnect Page do you say you can apply it to? AutoConnect's page generation (partly due to PageBuilder) is more than just page streaming. Ref. AutoConnectPage.cpp, AutoConnectAux.cpp.

In addition, if some parts of the page content are placed on an external file system, the user must upload the page content to the ESP module's file system for AutoConnect in addition to uploading the sketch. It will take more time and effort. You need to make a part of it, who is the sketch for? AutoConnect, which is supposed to be a utility, reduces user utility. I don't think it makes sense.

I have implemented it to support both ESP8266 and ESP32 with a program structure that is as integrated as possible. Recently, there is an increasing demand that only ESP32 is in the eye. A kind of resource management is required to make the language switch dynamically. There is no such resource on the ESP8266.
I don't know of any use cases where language needs to be dynamically switched in a minimum-size microcontroller like ESP in the first place. It means that multiple clients with different locales can access the Web Server of the ESP8266 host (same for ESP32) at the same time. How many use cases do you have for that?
I've developed many utilities based on the server model so far, but run-time multilingual support is more than just a string replacement. (Ifdef? It's a preprocessor instruction)