ITEAD Studio

Our problem is that we have to support up to 32 languages with a single application

On the grounds of academic debate, I would redefine what the problem is.

True.  An HMI can only have one default encoding.  Set with Device on toolbar.

 ... support of up tp 32 languages 

begs to ask, what kind of and level of language support

A Calendar in 32 languages, maybe so

Accompanied printed documentation, again maybe so

Which 32 languages is necessary, all required supported characters

Which MCU will be used to drive the Nextion and what resources it has.

What context Nextion is in and vocabulary of supported text

Programming approach to solve

Many considerations required - currently too few details.

There isn't a general tutorial for such.

  - but in programming almost everything is possible with the right code.

Sensor Values are numeric - so generally ascii 0 to 9 suffice

Standard Warnings - are generally static can be stored either as text or graphic

Sensor names either

   static - stored either as text or graphic

   dynamic ... requires data entry (this is where it becomes more complicated)

Nextion supports single byte characters or double byte characters

  - this is based on the chosen default encoding of the HMI

To support German, Russian, English - this is single byte encodings

  - for single byte encodings the supported char sets are iso-8859-X

Now a single byte character is 8 bits, 1 byte.

  - control characters of values 0 to 31 are not printable

    as are some extended ascii 127-255 also not printable.

So the game becomes one of arranging text of required characters

against the iso-8859-X encoding tables - with least conflict.

Which tables, depends on which languages.

When a table includes all required characters for application in that

language, then this table is good for your purposes.

32 languages will not require 32 tables

If external input is required to build text, this will depend heavily on

what device is being used and how it maps to characters

Russian code pages, versus double byte Windows, multi-byte Unicode or UTF8

MCUs are not going to understand characters per se

 - they are going to process bytes at the register level

If enough commonality is found, then perhaps 2 languages share 1 HMI

But perhaps multiple HMIs and load the corresponding TFT as required

   in total, less than 32 designs as some will share with another

How to swap TFTs from an MCU, such protocol is publically published

So it could indeed be accomplished, but it would indeed take effort.