On 7/27/2021 9:58 PM, Bret Johnson wrote:
i) NLS support: Is there anybody who can tell me if all DOS commands
support [J(a)|Nein] or [O(ui)|N(on)] etc. instead of [Y(es)|N(o)]? If
not, they should do it. As a translator you never know what to do.
That is rather one of the easier parts to accomplish. There is even a
DOS (INT21h/6523h) call to help with this...;-)
Supporting multiple languages brings up all kinds of technical
issues. E.g., there are at least three different ways to approach
this: compile all the languages into one executable file (makes for a
very large file and also requires recompilation if a new language is
added),
While technically possibly, this would be a complete nonsense approach IMHO
compile different executables for each language (creates lots of
different executable files where each needs a separate name),
That would be IMHO the most feasible approach. Though you don't need a
different executable file names, just subfolders for each supported
language. Pick your poison...
or have a "base" executable with separate "adjunct" files for each
language (probably the most efficient option in terms of total size).
Well, that would the the "kitten" approach.
A major issue is that interactive items (like Yes/No or
Abort/Retry/Fail) require two-way interaction. That is, in addition
to displaying different things on the screen for the different
languages, you also have different input keys that can respond to the
different options (e.g., Y/N for English and J/N for German). That
gets really ugly to program and from a design perspective it becomes
an issue as to where the store the input key data.
No, not really. It just comes down to proper designing an application in
the first place...
That is, particularly if you have a common "base" program with
separate language files, where does the data for the correct input
keys (which vary by language) get stored -- in the base program or in
the language file? Does the base program really even need to know
what language is being supported or can the base program be totally
independent of language and ALL the language data (both input and
output information) is contained in the language files?
This gets further complicated if you support languages that aren't
based on a Latin alphabet (Cyrillic, Arabic, CJK, Greek, and Hebrew
come to mind immediately) where the Code Page comes into play as well
(and the ASCII codes for the input key data can vary depending on the
current Code Page).
Well, that sucks, but to be honest, considering the (very) small
percentage of users that would benefit from this, I would not worry
about this at all....
I'm really wondering if anybody has really thought this all the way
through and has some sort of flexible structure figured out. I've
considered adding language support to some of my programs (if I could
get someone to do the translations), but just designing a support
structure to handle all the possibilities is pretty daunting.
Yes, I have done this (with a few colleagues) for a rather large DOS
based CAD system in the late '80s/'90s. Where we came up with a
kitten/cats like approach, which worked with scanning displayed texts in
the source code, adding a unique key in front of it, and customized
display/print routines that dynamically scanned for those keys and
replaced them with the translated texts from an indexed database file
(or just removed the key when no translation was provided).
I would for a first release (of any version) not bother with any
translation at all, just have working English language programs and then
worry about any translations later...
Ralf
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
