Re: How to add the second (or other) languages

On 16/02/2025 23:15, pozz wrote:

Il 12/02/2025 18:14, Stefan Reuther ha scritto:

Am 12.02.2025 um 17:26 schrieb pozz:

#if LANGUAGE_ITALIAN
#  define STRING123            "Evento %d: accensione"
#elif LANGUAGE_ENGLISH
#  define STRING123            "Event %d: power up"
#endif

[...]

Another approach is giving the user the possibility to change the
language at runtime, maybe with an option on the display. In some cases,
I have enough memory to store all the strings in all languages.

>
Put the strings into a structure.
>
   struct Strings {
       const char* power_up_message;
   };
>
I hate global variables, so I pass a pointer to the structure to every
function that needs it (but of course you can also make a global variable).
>
Then, on language change, just point your structure pointer elsewhere,
or load the strings from secondary storage.
>
One disadvantage is that this loses you the compiler warnings for
mismatching printf specifiers.
>

I know there are many possible solutions, but I'd like to know some
suggestions from you. For example, it could be nice if there was some
tool that automatically extracts all the strings used in the source code
and helps managing more languages.

>
There's packages like gettext. You tag your strings as
'printf(_("Event %d"), e)', and the 'xgettext' command will extract them
all into a .po file. Other tools help you manage these files (e.g.
'msgmerge'; Emacs 'po-mode'), and gcc knows how to do proper printf
warnings.
>
The .po file is a mapping from English to Whateverish strings. So you
would convert that into some space-efficient resource file, and
implement the '_' macro/function to perform the mapping. The
disadvantage is that this takes lot of memory because your app needs to
have both the English and the translated strings in memory. But unless
you also use a fancy preprocessor that translates your code to
'printf(getstring(STR123), e)', I don't see how to avoid that. In C++20,
you might come up with some compile-time hashing...
>
I wouldn't use that on a microcontroller, but it's nice for desktop apps.

 In some projects keeping all the translated strings is not a problem.
 All the gettext tools seem good (xgettext, marking strings to translate in the source code, pot file, msginit, msgmerge, msgfmt, po files, mo files, ..) except the final step.
 mo files should be installed in a file-system and gettext library automatically loads the correct .mo file from a suitable path. All these things are impractical on microcontroller systems.
 Is it so difficult to import mo files as C const unsigned char arrays and implement the gettext() function to search strings from them?
 

You know the answer...  a little Python script that reads mo files and generates files with C constant arrays.  You'd also probably need to make a few changes to the gettext language choice functions.  (I've used gettext with big Python programs, but never in embedded C code.)

Another approach could be to rewrite a custom msgfmt tool that converts a .po file into a simpler .mo file (or directly a .c file) that can be used by a custom gettext() function.