Hi, > On Mar 21, 2022, at 7:21 PM, Jim Hall <[email protected]> wrote: > > On Mon, Mar 21, 2022 at 5:41 PM Mark Olesen <[email protected]> wrote: >> >> Is it not possible to create maco wrappers around the new api to >> retain compatibility with the old? Sorry for my ignorance, I never >> used FD-NLS libraries. I would think it should be seamless and >> transparent. For me, the biggest change would be migrating data files. > > We already have the Cats and Kitten libraries, which mimic the Unix > catgets() function. Kitten is the smaller version of Cats. catgets() > is much easier to implement on a limited memory system like DOS than > gettext(). > > Jim
First, like Jim mentions... There is Kitten. There are also similar extremely light weight and very fast methods used by DOS programs. For example, some use hard coded assembly tables and are compiled into the executable. Those have more code dedicated to detecting the users language then what is used to handle the actual text. At present there is no such thing as FD-NLS libraries. When I say the FD-NLS desktop uses an “api”, this is internal to the application itself and has to deal with the git repository and the different formats and standards used by programs to handle the various types of NLS used. This “api” doesn’t have anything to do with DOS programs themselves. Nor would it be used in creating them. The “api” abstracts all different aspects of dealing with the different files, formats, locations and data structures needed to perform translations of the NLS for those DOS programs. But, the “api” (Application Program Interface or abstraction layer) is used by the desktop application could eventually be used by other utilities to perform various tasks on the different DOS program NLS files. Including things like conversion to PO and back again. It provides a single method for handling all of the different formats used so a single program can aid in creating and editing translations for the DOS programs. It is not for the DOS programs themselves. They already have their own NLS systems. I guess the the way to look at the FD-NLS Desktop app is it is for Translators not Programmers. It will provide translators a single easy way to manage translating the various forms of NLS used by DOS programmers regardless of what type of NLS they chose to use in their program. Or, at least that is the overall intent. After I finish implementing the cross-platform work arounds for Windows and Linux, step 1 will be complete. The macOS version is already available for use. Step 1 was to make translating package descriptions easier. The previous method required the translator to edit them in a spreadsheet program and convert to and from DOS codepages. While it was better than what was required even earlier. It had several aspects that were easy to make mistakes, miss things or even break the translations for that language. Step 1 fixes all those issues. It also provides some nice features and an much better experience to the entire process. When the FD-NLS Desktop project is finished, all aspects of providing translations for FreeDOS related programs will be improved. It could be as simple as just download the App and begin translating. With all such things (like interacting with GitHub), handled by the program. The end result could potentially remove any barriers for translators to provide contributions. But, it will take a while. :-) Jerome _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
