On Wed, Jul 28, 2021 at 7:15 AM Eric Auer <e.a...@jpberlin.de> wrote:
>
> COUNTRY=... and COUNTRY.SYS are not undocumented, but your
> choice of words hints at another idea: Do you suggest to
> introduce a TSR to handle string and key translations, to
> be used by FreeDOS apps? I think this would not save enough
> overhead compared to implementing translations in each app
> to be worth the incompatibility. Remember that our kitten
> implementation of catgets is very lightweight :-)
>
Although it's up to the individual developer, my preference and
recommendation would be to use the FreeDOS Kitten library for any C
program that wants to add support for different spoken languages
("internationalization"). There's a version for Pascal, too.
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/cats/
Although if you're using Assembly, there's no version of Kitten for
that. So that requires a different method.
I think using language catalogs is a very flexible way to provide
internationalization in a program. The tradeoff is a bit of
performance (reading the catalog) and some extra code to manage
everything. The benefit is you end up with *one* compiled program that
you use in every language instance, and it reads the message catalog
for the user's preferred language.
MS-DOS supported other languages by creating new compiled/assembled
versions of its programs. So there was an "English" (default) version
of MS-DOS, and a "German" version, etc. Each language release was sold
separately. Which made sense for the 1980s and 1990s where you
actually purchased the software you needed - you didn't download it
from a website. And the benefit here is that you have a small
distribution (because you aren't including language catalog files for
languages you don't need) and things are smaller and faster (because
all the text is "hard coded" into the binary.
But for a modern DOS that needs to support different languages by
different users in different countries, I think language catalogs (the
"Kitten" method) provide the best solution.
Jim
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
