Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: pozz <pozzugno@gmail.com>
Newsgroups: comp.arch.embedded
Subject: Re: How to add the second (or other) languages
Date: Sun, 16 Feb 2025 22:56:55 +0100
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <votn0r$pad8$1@dont-email.me>
References: <voii3i$28jmm$1@dont-email.me>
 <voioe3.598.1@stefan.msgid.phost.de> <voiu1q$2f5ap$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 16 Feb 2025 22:57:48 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f74bdbe09773e4d813c1959798f2cd87";
	logging-data="829864"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/96k/we17s7odoEieNR+HMVTPrS2APjkI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:KZNbEKWxKqglxMMRVIkpVvUNzN4=
Content-Language: it
In-Reply-To: <voiu1q$2f5ap$1@dont-email.me>
Bytes: 4256

Il 12/02/2025 20:50, David Brown ha scritto:
> On 12/02/2025 18:14, Stefan Reuther wrote:
>> 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.
>>
>>
>>    Stefan
> 
> 
> You don't need a very fancy pre-processor to handle this yourself, if 
> you are happy to make a few changes to the code.  Have your code use 
> something like :
> 
> #define DisplayPrintf(id, desc, args...) \
>      display_printf(strings[language][string_ ## id], ## x)

What is the final "## x"?


> Use it like :
> 
>      DisplayPrintf(event_type_on, "Event on", ev->idx);


Other problems that came to my mind.

There are many functions that accept "translatable" strings, not only 
DisplayPrintf(). Ok, I can write a macro for each of these functions.

I could have other C instructions that let the task more complex. For 
example:

char msg[32];
sprintf(mymsg, "Ciao mondo");
DisplayPrintf(hello_msg, mymsg);

Python preprocessor isn't able to detect where is the string to translate.