Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch.embedded
Subject: Re: How to add the second (or other) languages
Date: Mon, 17 Feb 2025 19:09:12 +0100
Organization: A noiseless patient Spider
Lines: 118
Message-ID: <vovu08$18l0n$1@dont-email.me>
References: <voii3i$28jmm$1@dont-email.me>
 <voioe3.598.1@stefan.msgid.phost.de> <voiu1q$2f5ap$1@dont-email.me>
 <votcl3$nc20$1@dont-email.me> <vout9p$12qr8$1@dont-email.me>
 <vovj7p$12c64$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Feb 2025 19:09:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="84427c50b3b38f0c33e226ebb268a6cd";
	logging-data="1332247"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/8L053ruVD3CuI4Vx/4YICe5RZp2hT7Fc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:imGld9VggLYPTIwXCv9wPDRllbA=
In-Reply-To: <vovj7p$12c64$1@dont-email.me>
Content-Language: en-GB
Bytes: 6051

On 17/02/2025 16:05, pozz wrote:
> Il 17/02/2025 09:51, David Brown ha scritto:
>> On 16/02/2025 19:59, pozz wrote:
>>> Il 12/02/2025 20:50, David Brown ha scritto:
>>
>>>>
>>>> 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)
>>>>
>>>> Use it like :
>>>>
>>>>      DisplayPrintf(event_type_on, "Event on", ev->idx);
>>>>
>>>>
>>>> A little Python preprocessor script can chew through all your C 
>>>> files and identify each call to "DisplayPrintf". 
>>>
>>> Little... yes, it would be little, but not simple, at least for me. 
>>> How to write a correct C preprocessor in Python?
>>
>> You don't write a C preprocessor - that's the point.
>>
>> Tools like gettext have to handle any C code.  That means they need to 
>> deal with situations with complicated macros, include files, etc.
>>
>> You don't need to do that when you make your own tools.  You make the 
>> rules - /you/ decide what limitations you will accept in order to 
>> simplify the pre-processing script.
>>
>> So you would typically decide you only put these DisplayPrintf calls 
>> in C files, not headers, that you ignore all normal C preprocessor 
>> stuff, and that you keep each call entirely on one line, and that 
>> you'll never use the sequence "DisplayPrintf" for anything else.  Then 
>> your Python preprocessor becomes :
>>
>>      for this_line in open(filename).readlines() :
>>          if "DisplayPrintf" in line :
>>              handle(line)
>>
>> This is /vastly/ simpler than dealing with more general C code, 
>> without significant restrictions to you as the programmer using the 
>> system.
>>
>> If you /really/ want to handle include files, conditional compilation 
>> and all rest of it, get the C compiler to handle that - use "gcc -E" 
>> and use the output of that.  Trying to duplicate that in your own 
>> Python code would be insane.
> 
> And this is the reason why it appeared to me a complex task :-)
> 
> You're right, this is my own tool and I decide the rules. Many times I 
> try to solve the complete and general problem when, in the reality, the 
> border of the the problem is much smaller.
> 
> The only drawback is that YOU (and all the developers that work on the 
> project now and in the future) have to remember your own rules forever 
> for that project.

This is embedded development.  It is not always easy or straightforward. 
  When a problem seems difficult, re-arrange it or subdivide it into 
things that you /can/ solve.  Here I've given one solution (of many 
possible solutions) - it makes some things easier, but also requires 
other changes.  You can use a big, general solution like gettext and 
document how that should work in your development, or you can make a 
much smaller and simpler, but more limited, custom solution and document 
/that/.  There are /always/ pros and cons, tradeoffs and balances in 
this game.

> 
> 
>>> This preprocessor should ingest a C source file after it is 
>>> preprocessed by the standard C preprocessor for the specific build 
>>> you are doing.
>>>
>>> For example, you could have a C source file that contains:
>>>
>>> #if BUILD == BUILD_FULL
>>>    DisplayPrintf(msg, "Press (1) for simple process, (2) for advanced 
>>> process");
>>>    x = wait_keypress();
>>>    if (x == '1') do_simple();
>>>    if (x == '2') do_adv();
>>> #elif BUILD == BUILD_LIGHT
>>>    do_simple();
>>> #endif
>>>
>>
>> The really simple answer is, don't do that.
>>
>>
>>> If I'm building the project as BUILD_FULL, there's at least one 
>>> additional string to translate.
>>
>> The slightly more complex answer is that you end up with an extra 
>> string in one build or the other.  Almost certainly, this is not worth 
>> bothering about. 
> 
> Oh yes, but that was only an example. We can think of other scenarios 
> where the preprocessor could change the string depending on the build.
> 

As the saying goes, you can burn that bridge when you come to it. 
Imagining all the possible ways things can go wrong or be complicated 
can be a lot more effort than getting a solution for the actual 
practical situation.


I am not guaranteeing that my ideas here will be ideal for your needs. 
But it is roughly in the direction of a system that I have used 
successfully myself, and it's where I would start out in the situation 
you described.  Hopefully it gives you a good starting point for your 
own solution - or at least something to compare to other potential 
solutions when judging them.