Sujet : Re: How to add the second (or other) languages
De : pozzugno (at) *nospam* gmail.com (pozz)
Groupes : comp.arch.embeddedDate : 16. Feb 2025, 22:56:55
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <votn0r$pad8$1@dont-email.me>
References : 1 2 3
User-Agent : Mozilla Thunderbird
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.