Hello Tom,
> Am 04.03.2025 um 00:42 schrieb tom ehlert via Freedos-devel
> <[email protected]>:
>
> My suggestion would be to attach these language data to the end of the .exe
> file, so there is
> only one resource (the .exe file) to be managed. And updating the .exe also
> updates the language resource.
this could easily be done, and came also into my mind previously. The reason it
is NOT done right now by the current FDISK is to reduce the binary size of the
.EXE, as it is used for example on the SvarDOS installation floppy, where
"every byte counts". Could be made a build option, though...
> A horrible idea. When navigating (discovering) software written by other
> people it's
> extremely helpful to have message strings sprinkled through the sources.
> ...
> result = dosomething();
>
> if (result != 0)
> printf("%s\n", kittengets(1,22, "can't write file. Disk full??"));
>
> is much easier to navigate then
>
> if (result != 0)
> printf("%s\n", kittengets(1,22));
>
Yes, I generally agree. This is one thing that bothers me with the current
implementation. With one of the next iterations I will probably do something
like this as a compromise:
puts(svarlang_str(DISK_FULL_ERR));
Or even
puts(TX(DISK_FULL_ERR, "can't write file. Disk full??")));
With the header containing the textual identifiers of the messages being
automatically generated by the translation tool. That should be sufficient for
the programmer to understand the context.
Question would be what to do with the string constants in the second case. a)
include them in the binary as-is to use as default language strings or b)
"remove" them via macro and treat them like the ones of the translated
languages. b) is probably more efficient and portable, as when loading a
translation, one had either to overwrite the C string constants (highly
dangerous) or allocate double the memory to also hold the translated strings in
memory.
So the tendency at the moment is towards the
puts(svarlang_str(DISK_FULL_ERR));
style.
Bernd
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
