> On Mar 3, 2025, at 4:51 PM, tom ehlert via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > Dear Bret, > >> I am still trying to develop a good infrastructure in the programs to handle >> multiple languages, though -- one where I wouldn't necessarily need to be >> very involved in the process of adding new languages to a program. KITTEN >> really isn't that useful for me for multiple reasons, one major reason being >> that, at least as far as I can tell, it is only for C and not ASM. > If you can't interface to C, you will have to write your own implementation. > However don't fear: KITTEN is definitively no rocket science.
There is nothing wrong with Kitten. Personally, I prefer my own NLS. It is similar. However, it supports text keys and has a few other minor differences. It is the NLS system used by V8Power Tools and a bunch of my other programs. I find it much easier when looking at the translation file to easily understand what “ERROR.NO-DISK=“ as apposed to “22.3=“ However, I do use a couple other NLS formats. But generally, that is for very specific reasons and seldom occurs. Some (like for PGME) are weird and complex. That one is similar to an INI file, has bizarre line extensions and other strange things. However, it works well for the custom object oriented framework that PGME is built upon. > >> It also isn't very "flexible" in the types of text it can handle (e.g., it >> can't directly handle multiple-line strings. doesn't have flexible >> formatting for input parameters like numbers, doesn't really allow for >> manipulating things like indentation and spacing/text alignment, only >> handles output rather than input, etc.). > This goes WAY beyond kittens intentions. linux and windows have attempted > internationalization efforts for many decades; may be look there for > inspirations. > However you have to do this on your own. You can easily work within the limitations of Kitten to get the flexibility you want. But, Tom is correct and you will have to put in some effort. For example, let’s say you want a string that says something like “Sorry Bret, there was 1 file not copied.” 1.0=Sorry %1, there was %2 %3 not copied. 1.1=file 1.2=files You can fetch the string, then replace the variables. Not very hard. :-) > >> Anyway, in trying to set up the environment in my programs, I have run into >> something of a dilemma. The LANG environment variable seems to be the >> "controller" of what LANGuage the user wants/prefers to see messages in. >> AFAIK, the LANG environment variable really wasn't used back when MS was >> "managing" DOS and is something relatively new that I think was "invented" >> by FreeDOS (though I'm not 100% sure about any of that). I've never seen >> any documentation, formal or otherwise, on exactly how the LANG environment >> variable should be used. > > The *FreeDOS* installer installs in autoexec.bat for germans > > set LANG=DE > > kitten concatenates this with the programs name to programname.DE and expects > to find this file. > Yep. Also, a lot of other programs with NLS support do no use kitten do the same thing. For example, the FDHELPER package contains a couple V8Power Tools based batch files. Once such batch is the CDROM.BAT which initialized the CD/DVD drive at startup. That batch looks for a %NLSPATH%\CDROM.%LANG% file to use for it’s text. If that file does not exist, it tries to use %NLSPATH%\CDROM.EN. If it cannot find that file either, it will fall back on NLS that is embedded into the batch file itself. > >> My assumption is that what is contained int eh LANG environment variable >> should be a two-letter code, and an extension to this assumption is that the >> two-letter code should correspond to the "official" two-letter language >> codes as defined in ISO 639. I really, really doubt that DOS will support >> all of those (nearly 200) languages, but will support several of them to at >> least some degree. > > It's easy to support 26*26 or even 26*26*26 languages. > I really, really doubt we find that many translators willing to do the work > for free. > > >> That brings me to the dilemma. In addition to the language, DOS also has >> three other related items: Keyboard Layouts, Countries, and Code Pages. >> While all of these items are highly inter-related they are also distinct and >> separate. The main question I have is in the two letter codes for LANGuage >> and their relationship to the two-letter codes for countries and keyboard >> layouts (code pages don't have two-letter codes). > Nobody enforces this relationship. Feel free to setup your own rules. > >> Anyway, my basic question is: should it be allowed to "intermix" the two >> letter codes? For example, if I live in the US and want my program >> interactions to be in English, is the LANG environment variable required to >> be EN or can it also be US (or UK or AU or NZ or ...)? That is, can the >> LANG environment variable correspond to a country code where the "common" >> language is the one you want to use? I know what I think the answer >> _should_ be (at least if we don't want to fundamentally change how DOS >> handles languages and code pages and etc.), but would like to see what >> others think. > > your program. your rules. I Program! I Rule! Lol. :-) (For readers whose native language is not English… In this context, rule can mean awesome/great.) > >>> It is not always just 2 letters. For example, Portuguese is PT and Brazilian >>> Portuguese is PTBR. > >> Two thoughts this brings up. One is that we are not following the ISO >> standard. > So what? Which ISO standard anyway? > >> Perhaps not a big deal, but that means we are on our own and will definitely >> need to document everything > Don't bother. In my experience nobody reads documentation. > >> to avoid confusion and "maverick programmers". > 30 years into the FreeDOS business the risque by "maverick programmers" seems > low. > > > >> The other thought is that this is going to create problems with 8.3 file >> names where the language abbreviation must fit into the three letter file >> extension. This, I think, implies that LFNs are _required_ whenever we >> support multiple languages? I also see that some of the existing language >> files have file extensions like .FR.UTF-8, which at least seems to imply the >> use of both LFNs and UniCode which are both outside the realm of "regular" >> DOS. > right. The files which have a “.UTF-8” extension are for translators only. They are present to help prevent or recover from mangled translations. It is very easy to damage translations in modern text editors when trying to edit the codepage versions. On the FD-NLS repository, the extensions for translations are to be 8.3 compatible and not require LFN. This does not mean the extension is limited to 8.3 characters. It simply means the 8.3 portion cannot conflict with any other language. >> BTW, one option I was considering is a single .LNG file (or something) with >> all the translations inside a single file instead of needing a separate file >> for each language. I don't know if that's a good idea or not -- it's >> certainly incompatible with KITTEN, at least in its current form. > Your program. Your data. KITTEN has no intention to read your data. > > Tom The primary FreeDOS installer does this for a couple things at runtime. But, those mixed codepage files are generated by the RBE when creating a release. But, I highly recommend not doing that. It is near impossible for a translator to edit a text file in a modern editor that contains various mixed codepages. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
