> On Oct 25, 2015, at 8:56 PM, Jerome E. Shidel Jr. <jer...@shidel.net> wrote: > >> >> On Oct 25, 2015, at 7:00 PM, Eric Auer <e.a...@jpberlin.de> wrote: >> >> >> Hi Jerome, thanks for adding localization to VECHO, but: > > Like said, sort-of localization. It is not really localization. It is > basically > a formatted string lookup, parser and processor thingy. > >> >>> vecho /t %FLANG% HELLO %TFH% "%OS_NAME% %OS_VERSION%" %TFF% >>> >>> At the point that line is invoked, >>> %FLANG% points to a file called A:\FDSETUP\SETUP\EN\STAGE300.DEF >>> %TFF% and %TFH% are color names Black and Red. >> >> You could read a variable %V8LANGFILE% directly from the environment, >> as using the file name as command line option uses up possibly dozens >> of bytes of precious space in the command line ... >> >> An even nicer idea might be making VECHO use a style more similar to >> what existing localized tools for FreeDOS already use: A file called >> VECHO.XX where XX is the current value of %LANG%, in any directory of >> the semicolon-separated list of %NLSPATH%, containing lines similar to > > The logic in the installer use the %LANG% value to determine what file to > use to pull the text from. Also, the installer will break the “language” > files > into a bunch of files. For example, > > EN\STAGE300.DEF for the welcome screen. > EN\STAGE400.DEF for partitioning screens. > EN\FDINS100.DEF ……. > etc.
Actually, this is not 100% accurate. Since, the install media boots with disk caching enabled. I’m going to see how it performs with all the text in 3 files. FDSETUP.DEF, FDASK.DEF and FDINS.DEF. I did build in the ability to just override the text individual parts. So, If reloading all of the text each time is to slow, I can just split it up. > > A little bit of a pain. However, no sense wasting time loading and > searching through 100 lines of strings 5, 6, 7 or more times to > make one simple prompt. Some serious performance penalties > to stick all the text in one file. > > Also, I can easily have multiple files for the same part. For > example, basic mode and advanced mode can use different > text. Just add a EN\STAGE300.ADV file. > >> >> 1.42:"Welcome to the installation program for" /f Red >> >> and where you would invoke VECHO roughly as follows: >> >> VECHO /NLS:1.42 "%OS_NAME% %OS_VERSION%" /f Black "." >> >> In other words, /NLS:code inserts a message from the NLS file, here >> omitting the %NUMBER style variable support for a bit more simple >> processing. You could instead use multiple /NLS:... options such as: >> >> VECHO /NLS:1.42 "%OS_NAME% %OS_VERSION%" /NLS:1.43 >> >> ... where (obviously) message 1.43 would have to be defined as: >> >> 1.43:/f Black “.” Just another note. The colors are not constants. Based on what settings are in the Advance and Basic themes. They can change at any time if the user switches to or from advanced mode. > > Don’t you think this is a little easier to read? (excerpt) > > HELLO="Welcome to the installation program for " /f %1 "%2" /f %3 "." > HELLO_ADV="Welcome to the advanced installer for " /f %1 "%2" /f %3 "." > PROCEED="Do you wish to proceed?" > YES=" Yes - Continue with installation" > NO=" No - Return to DOS” > > If you really want to use numbers, you can. The “ID” can be anything that > does NOT > contain spaces and is immediately followed by an = symbol. These all would > work as > different ID’s: > > HELLO=“Hello” > Hello=“Hello again” > !Hi="High there” > 1.43=“That was 1.43” > 1.44=“That is a number too” > *HI=“Not to low” > > However, if you put spaces or exclude the = symbol in there it will never > match and > these would just get ignored: > > ; Test=off > NO =NoMatch > # Say high to Bob. > Or goodbye to Sally. > > Also, Windows or Unix Line endings are supported. :) > >> >> Note that NUMBER.NUMBER style codes are what the Catgets/Kitten message >> files traditionally use. Even if you only modify your VECHO to search >> the NLSPATH directories for a VECHO.%LANG% file while keeping the file >> format of your ".DEF" files for that, you still have advantages: This >> style would avoid having to pass the /t %FLANG% option manually and it >> will make it easy to have multiple VECHO.* files for various languages >> prepared without needing extra batch processing to select one :-) > > I see what your saying. But, using a environment variable and the standard > localization would actually be very problematic. Basically, try not think of > vecho > as a program. Think of it as a tool that a batch program can use. So, by > using > an env var any batch program that uses vecho would be locked into the same > language file. There can be ways around that issue. But, I think by telling > vecho > what file you want leaves all responsibility for managing it up to the batch > program. I think is well suited for such a tool as vecho to handle it > this way. :) > >> >>> vecho "Welcome to the installation program for " /f Red “FreeDOS 1.1a" /f >>> Black "." >>> >>> There main reasons I built it into vecho were: >>> >>> It and maybe vstr are the only things that will ever need it. >>> Performance and Compatibility, no piping or shelling needed. >> >> Indeed :-) Thanks! >> >>> Longer text supported. (127 max command line, 96 in batch filed can be >>> expanded up to 256 characters.) >> >> Why 256? Message files in theory support arbitrary line lengths :-) > > I felt that 127/96 is a little restrictive. Especially, when you start > throwing in > multiple text color changes an such things. So, I picked 256. :) > > The lines in the text file are not restricted to any length. However, once the > “parsed data buffer” is full any additional text is ignored. Mostly, that is > because several of the memory managers have issues when com files > try to use standard DOS function calls to allocate additional memory. It is > easier to just build a buffer into the binary. At present, vchoice is the > only tool at present that will allocate some memory at runtime. But, it has > a bunch of fallback code to continue to work if it is unable to allocate any > memory. > >> >> Note that the Catgets / Kitten files also support "# this is a comment" >> style lines (they have to start with the # char) for extra structure. > > vecho can do that as well. sort-of. Actually, the file is just a text file. > vecho > does buffered reading of the file and searches for a line that starts with > ID= and uses the first one it finds. Everything after the = on the same line > is > assumed to be the text to process. All other text is ignored. So, you could > use > !, #, ; or whatever to comment lines. > >> >> Cheers, Eric >> >> PS: If you compare VECHO to LOCALIZE, you will see that LOCALIZE also >> has a special syntax for a fallback message which is used if either no >> message file is found or the selected message is not found in that. It >> can also help with readability of batch files to have fallback texts. >> > > Since it is not truly localization, vecho’s text formatting parsing > translating thingy > does not do any kind of fallback. However, that being said, I stuck some of > that > in the FDI setup program. :) > >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
