Hi,
> On Jul 29, 2021, at 8:17 PM, Jim Hall <jh...@freedos.org> wrote:
>
> 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.
Agreed. :-)
Although I use my own code to support multiple languages and it differs some,
the end result is similar and it could be called “Kitten” like.
Outside of the “developer’s" point of view, there are a couple others aspects
to consider as well.
Mostly, it comes down to the Translators and maintaining translations for
multiple programs and languages. A Kitten-like language file format provides a
fairly uniform and understood source for someone to work from to provide a
translation. I believe it is much easier for them than dealing with source code
files that can vary in programing language and restrictions.
Also, maintaining large numbers of translations is easier when they are in a
Kitten-like format. For example, the new home for translations has a couple
utility scripts. These tools analyze the translations and generate reports. The
main such utility aids Translators in determining what programs need translated
or updated translations. It does this by comparing timestamps and string keys.
It is far from perfect. But, much better than nothing. It has already assisted
Translators several times in spotting missing information. But, that tool can
only perform most of it’s tests against Kitten-like translation files. Ones in
source code format like CTMOUSE, require manual examination to determine
anything at all about their status.
As a reminder…
If you want to contribute new or updated translations, please visit
https://github.com/shidel/fd-nls <https://github.com/shidel/fd-nls> and be sure
and check out the https://github.com/shidel/fd-nls/blob/master/report.txt
<https://github.com/shidel/fd-nls/blob/master/report.txt> file. There are many
programs that could use translations. Some programs are even very common
languages like Spanish.
Also... If you are a developer and have updated you program, please let me know
or issue a pull request to the project so the translations there can get
updated. It makes it easier for the Translators to spot and update things that
need worked on.
:-)
Jerome
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
