> On Jul 19, 2021, at 9:27 AM, Eric Auer <e.a...@jpberlin.de> wrote: > > > Hi Jerome, > >> Out of curiosity, what would your perfect solution to multi-language support >> entail? >> Everyone live with English, compile your own or something else entirely? > > the current solution is quite nice if you ask me: You can create a > command.com in the language of your choice by concatenating a binary > file and a message file into a command.com file, which can be done > either by hand or as part of the install process. People can keep a > small number of command.com files in their preferred languages and > use a config sys menu to select the shell of their choice. Actually > cutemouse supports a similar mechanism to have a compile/assembly > time choice of ctmouse message languages :-)
I disagree for many reasons. A new user is highly unlikely to even know they can splice a different language onto the end of the shell. Many of them can barely navigate the file system and do not know how to even unzip a zip file. So asking them to know how to combine two files into a language specific shell is asking a lot of a novice user. If I follow the logic of tacking on language data to the end of each program that supports multiple languages, the task is cumbersome for a user. At that point, you would probably be better off just supplying language specific versions of the OS. Who is up for 7 different release media in 13 different languages? That’s 91 different downloads not counting the CD Boot Floppy or Bonus CD. But, might as well provide them for another 26 downloads. 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. 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. Lets take a end user utility boot floppy as an example. Lets assume it has users that speak multiple languages. Lets assume the users will do some simple tasks like copying or editing files. During boot, you would select your language and start the shell with the appropriate language so messages and errors are readable by the user. With 10 variations of COMMAND sitting on the diskette, nearly half it’s capacity is already used. Sure, they could be work-arounds employed. But, this is an extreme example. IMO a more elegant solution is to provide a more dynamic way to utilize the available translations through an external resource. Providing a way for users to change the language on the fly without needing to go through the process of combining files or having multiple copies. Sure, I can see that being able to splice the language into onto the shell can be very useful to some. And, by no means am I suggesting removing that capability. I’m only suggesting what I think is a reasonable method of being able to switch languages on the fly. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
