Hi Jerome,
of course you can say you prefer a command.com which can load translations on the fly. On the other hand, you know that the installer could do whatever it takes to put a command.com in the desired language on the fixed disk of the user :-) Actually my 3 floppy Brezel distro already was large enough to include ingredients for translated command.com, but given that it did not have any installer, it only had a readme for the magic "copy stub + languagefile command.com" step, which is not THAT hard to do, but of course nicer if it is done by the installer after asking for the user language and preferred keyboard layout (!) which then creates some custom default config, with comments explaining which things users can change manually at a later moment. > Who is up for 7 different release media in 13 different languages? Not needed, just let the INSTALLER dynamically mix and match. > Or, the installer could spend extra time and create all of those special > skews > during the install process. But, that still leaves the user or or less stuck > with > the language that gets installed. They would probably need to reinstall the > OS if they wanted to change languages. You even had to buy a new copy if you wanted to stop using German MS DOS and switch to French MS DOS. Nobody cared. But if you want to be nice, install a TOOL which helps the user to install new command.com languages but pre-installing all ingredients and a little batch script, no big magic. > Or, you can copy the program stub and the languages and a combined version > to the drive during install. But, having multiple copies of each version seems > rather wasteful. Only very few apps are affected by this. For command.com, it is good to have everything in one file. For cutemouse, you would not want a TSR to have to load extra files either. For most apps, it is okay to load extra files, but even in those cases, it is important that they can work in English when somebody happens to have copied only the main binary, or translated messages are inaccessible for other reasons. I think if you want 10 languages of command.com on a single floppy, it will not make much difference whether you have pre-compiled binaries or separate message files. Actually combining ingredient files on the fly is quite efficient and you can use compression :-) Note that even LC_MESSAGES .mo files in Linux are binary, you cannot simply write them in a text editor, but need special tools to "compile" them before you can use them to change languages on the fly. Do users really want to switch languages at any moment? I think not. Being able to switch by loading a new copy of the shell, at boot or later, is more than MS DOS did. Do users really lack the skills to create command.com in their preferred language or languages? If they cannot run a single COPY command after reading a readme, we can come to the rescue by letting the installer take care of this, or provide a tool to add language specific binaries later. If I was able to support multilingual command.com on a three floppy distro with all of BASE, you can do it on a CD ISO. I had pre-created English and German command.com on one of the disks and zips with ingredients for 10 more languages. It came with a batch script (0.9 kB) which did all of the work after the user had to edit only one word in the bat: The name of the language, for which "fixstrs" got called. Most of the 0.9 kB were comments explaining what happened. Eric PS: Running fixstrs instead of offering pre-fixed files was more elegant, I think. So the entire process became: fixstrs spanish if exist strings.log type strings.log if not exist strings.dat goto failed copy /b xmsswap.cln + strings.dat command.com :failed This uses default.lng, spanish.lng, xmsswap.cln, fixstrs. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
