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

Liste des GroupesRevenir à ca embedded 
Sujet : Re: How to add the second (or other) languages
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.arch.embedded
Date : 17. Feb 2025, 19:09:12
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vovu08$18l0n$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
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.

Date Sujet#  Auteur
12 Feb 25 * How to add the second (or other) languages13pozz
12 Feb 25 +* Re: How to add the second (or other) languages11Stefan Reuther
12 Feb 25 i+* Re: How to add the second (or other) languages7David Brown
16 Feb 25 ii+* Re: How to add the second (or other) languages4pozz
17 Feb 25 iii`* Re: How to add the second (or other) languages3David Brown
17 Feb 25 iii `* Re: How to add the second (or other) languages2pozz
17 Feb 25 iii  `- Re: How to add the second (or other) languages1David Brown
16 Feb 25 ii`* Re: How to add the second (or other) languages2pozz
17 Feb 25 ii `- Re: How to add the second (or other) languages1David Brown
16 Feb 25 i`* Re: How to add the second (or other) languages3pozz
17 Feb 25 i +- Re: How to add the second (or other) languages1David Brown
17 Feb 25 i `- Re: How to add the second (or other) languages1Stefan Reuther
13 Feb 25 `- Re: How to add the second (or other) languages1Niocláiſín Cóilín de Ġloſtéir

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal