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.
> 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. > 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. > 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. >> 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. > 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 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
