Hallo Herr Jerome Shidel, am Montag, 19. Juli 2021 um 17:04 schrieben Sie:
> Hi Tom, > On Jul 19, 2021, at 10:17 AM, tom ehlert <t...@drivesnapshot.de> wrote: > [..] > similar to what original MSDOS did: have a language specific > distribution for everything. > this could be done the way COMMAND does this: somhow combine (actually > append) the translated stuff to the .exe and have kitten figure this > out. > this could be either > attach all translated stuff to the program, select language at > runtime, using %LANG% > or attach only one selected translated stuff for the default language. > in either case copying the program also copies the relevant resources. > As a perfect world solution, it isn’t a terrible idea. :)) > Lets assume the installer asked not only what language was going to > be used. But, also provided a method for the user to pick any > additional languages the user desired. It would then tack those on > to the executable as well. The programs themselves could be modified > to pick the appropriate one from the set of attached languages > instead of loading them from disk. The end of the program + > languages file could contain a signature and marker to the start of > the language data. That way, a user could run a special tool to > change those languages and default language at any time, even after > installation. That would also provide a way to update just the > translations. This would reduce file system clutter and prevent > issues with translation files being forgotten during copying. here you have something like 98% agreement with my thoughts that I had a few years ago, but was too lazy to implement. however I might be much more motivated to give it another try if acceptance is likely. like the installer is taught that the primary language is portugese, but spanish is also fine (if available). then the 'language compiler' attaches portugese and spanish (language) resources, indicating portugese preferred. behaviour would be no SET LANG=XYZ --> use portugese SET LANG=PO --> use portugese SET LANG=SP or no portugese translation available --> use spanish SET LANG=EN --> use build in english translation SET LANG=TR --> use portugese > I really only see two potential trade-offs. > First, is an unknown and would require testing. just as everything... > For programs with > little translated text (most of them), it is probably faster to load > all the translations along with the executable. But for some > programs (Like PGME, HELP), translations can be 30K + per language. > With 10 different languages (currently PGME only has 4 languages > other than English), it would be faster to load the executable and > translation file separately. if just attached to the executable, the resources aren't even loaded, and must be loaded separately anyway. however load times are probabbly irrelevant anyway. > But, huge amounts of translated text > are rare. Other than help, I don’t thing any part of BASE has large > amounts of language translations. Performance testing would need to > be done. But, overall it would probably be a little quicker. > Second for COM files, you would need to load it all at once > requiring more RAM for the initial loading and possible preventing > some memory resident programs from be able to load into upper memory > on some computers. But again, this would probably not effect many > programs. Also, it would reduce complexity in simple programs and probably > speed up loading time. COM files should have died with CP/M. Now we have 2021. > I don’t see that tacking a bunch of translations onto the end of > the program as being worse than using an external language resource. > In some ways it is much better. But, it does have its own set of trade-offs. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
