Hallo Herr Bernd Böckmann via Freedos-devel,
am Dienstag, 4. März 2025 um 01:18 schrieben Sie:
> Hello Tom,
>> Am 04.03.2025 um 00:42 schrieb tom ehlert via Freedos-devel
>> <freedos-devel@lists.sourceforge.net>:
>>
>> 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??")));
In general, I would agree that DISK_FULL_ERR is better then 2.3
In this case, not so. Because:
When writing new code,
1) puts(svarlang_str(2,3,"can't write file. Disk full??"));
2) puts(svarlang_str(DISK_FULL_ERROR,2,3,"can't write file. Disk
full??"));
3) puts(svarlang_str(DISK_FULL_ERROR));
1) the next programmer sees immediately what's going to screen. in a single
place.
its easy to
a) #define svarlang_str(a,b,message) __svarlangstr(a,b)
or (if no translation is required)
#define svarlang_str(a,b,message) (message)
if you think that strings don't belong into the program, but rather into an
external resource.
for a) you can easily write a program to extract 2,3,"can't write file. Disk
full??" to PROGNAME.EN resource
this program can also check if numbers are doubly used, if they are new
(wrt. old resource) etc.
DSK_FULL_ERROR makes this more difficult.
in addition the translater sees that the message "can't write file. Disk
full??" allows for ~20 characters on screen.
If the message is
puts(2,3,svarlang_str(2,3,
"can't write file. The Disk is full.\n"
"it is recommended to run our disk cleanup tool XYZ\n"
"if nothing helps buy a bigger disk\n"
));
see that 2,3 is better (for the translator) then DISK_FULL_ERROR?
2) requires an extra file ERRDEF.H with
#define DISK_FULL_ERROR 2,3
3) as in 2, but there is no automatic synch between program and language
resource
puts(svarlang_str(DISK_FULL_ERR));
> 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
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
Mit freundlichen Grüßen / with kind regards
Tom Ehlert
+49-15151898538
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
