Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: pozz Newsgroups: comp.arch.embedded Subject: Re: How to add the second (or other) languages Date: Sun, 16 Feb 2025 23:15:21 +0100 Organization: A noiseless patient Spider Lines: 65 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 16 Feb 2025 23:16:14 +0100 (CET) Injection-Info: dont-email.me; posting-host="f74bdbe09773e4d813c1959798f2cd87"; logging-data="829864"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+o/AtseX/cb6uhCbg5Q6/rxPJ1v862VUg=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:+GCR431doOX5UtFKj0CLKDtFJO0= In-Reply-To: Content-Language: it Xref: csiph.com comp.arch.embedded:32339 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? 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.