What we would probably need is a Unix-style NLS system. under Unix you would have
LANG=PT_PT.latin1 or LANG=PT_BR.UTF8 It's not only about messages in programs, but date formats, currencies etc. On Mon, 3 Mar 2025 at 20:13, Jerome Shidel via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote: > > > > > On Mar 3, 2025, at 12:51 PM, Bret Johnson via Freedos-devel > > <freedos-devel@lists.sourceforge.net> wrote: > > > > I am trying to add international language support to at least some of the > > programs I am updating. So far, I have had some interaction with Thraex > > regarding French and Turkish translations for some of the programs, and am > > very grateful for what he has provided thus far. > > > > 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. 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.). > > > > 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. > > > > 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 is not always just 2 letters. For example, Portuguese is PT and Brazilian > Portuguese is PTBR. > > > > > 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). > > > > As an example, for America the two-letter country code and "standard" > > keyboard layout codes are US, but I'm aware of at least four other > > "standard" keyboard layouts that are sometimes used in America, (Dvorak, > > Left-handed Dvorak, Right-handed Dvorak, and Colemak), and there are also > > at least three other countries that use the English language (Great > > Britain, Australia, and New Zealand). I also know that even though all > > these countries use English, there are dialectical differences so that > > something written for an American audience wouldn't necessarily be > > understood correctly by an Australian audience, and vice versa. > > > > 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. > > > > > > > Bret > > > > > > _______________________________________________ > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel