Translations

[PerditionC]

Currently FORMAT is being updated to support translated messages.

Please review the NLS\format.en and provide any feedback or suggestions for improving translations.

The originally posted set 3 (detailed help) has been revamped so it is now free flowing text. The help text, while should cover the same information, can be structured in a way that fits with language being used.
Existing translations will need to update set 3 to take advantage of this, but should (hopefully) work fine still.

The short help message needs a similar treatment, but there is two versions, one with LEGACY_HELP information and one without. I think the best action may be to split set 2 into two different sets (duplicating messages). Set 2 and 200?

Some strings were reworked to full sentences or otherwise modified to not require English phrase order. Please add to discussion or file an issue for any messages that need reworking for a correct translation. This is especially useful for upcoming Display_Drive_Statistics() work which will be displaying numbers and possibly other functions I haven't looked into yet.

Future FORMAT.EXE will likely be compiled with compact memory model so data can use more than 64KB, allowing translation sets to be loaded even if exceeds available 8KB free in near buffer.

Any suggestions or comments?

[andrewbird]

nls: 4.1-4.4 seem to be fragments of a single sentence.

[PerditionC]

Yes, this is due to the actual characters displayed are generated from a loop at runtime and printed 1 at a time, so 4.1 & 4.2 is shown before printing valid characters and then 4.3 is repeated for each character. Same for 4.4 and 4.5 except these are characters not accepted. I'm open to suggestions for how to reword or restructure this section.

[PerditionC]

short help is now implemented like the long help option. If format is compiled with LEGACY_HELP then set 20 is displayed (used 20 instead of 200 as kittenc will not round trip 200 correctly) and will show set 2 otherwise.

Unfortunately this did break the existing translation catalogs, as I had to move a couple messages out of the set as they were conditionally displayed depending on if longhelp option provided or not.

[PerditionC]

There are several other sentence fragments/phrases in section 4. I'm not sure if the word ordering is correct for all potential translations - would it be better to just duplicate the phrases and make them all complete sentences? e.g. see 4.27-4.32 and 4.33-4.35

[PerditionC]

I added a header to the source catalog file. Its optional, but has some useful information such as the codepage the source file is in and what codepage should be used to display the messages. This information will be embedded in the compiled catalog file when using future release of kittenc.

[PerditionC]

Prerelease version posted - all non-debug messages support translation. Need to review and possible rework some sections and/or add missing translations based on translators feedback.

https://github.com/FDOS/format/releases/tag/v0.92a

[cardpuncher]

Hi,
Thanks for the prerelease version. I played with it a bit and think I found some strings that can be added to the message catalog, please see the screenshots below.
First of them is when format thinks that the floppy is write protected, the second is when I try to format the non existent B: on VirtualBox which apparently results in a timeout, the third shows a string that may have been overlooked ("Saving UNFORMAT information...") during a format a: -- and the final one shows some funny characters after a format /af I just wanted to ask if that was normal.

[PerditionC]

definitely missed one there with the "Saving UNFORMAT information"; looks like I'm missing passing the option to the translated string on the last one; the first two I will have to check, but I think that's the large group of DOS error messages that I skipped over, so will need to add those too. Thanks for checking.

[fritzmueller]

Hi,
I just work on the german translation, hope I will be able to finish it this week.
I have some questions:
a) Can you add the german translation when it is ready as I have the feeling that a lot of german text is bad or misunderstandable. Especial with variables, as english grammar differs from other grammars, sometimes the first english words appear at the end of the german (maybe turkish and french version too) text, so it is helpful to see the text at work - this may cause problems with variables.
b) I noticed that actually the en/fr/tr text is inside of the .exe file. Will this stay or will you work with format.de/en/fr/tr files at C:\freedos\nls as most other programmers do? This makes it easier to test format text and to see the result of text modifications - and the .exe stays small.
c) One more thing: Till today I saw no working "format b:" There were always error messages. I think format a: and format b: should work. I already tested it fine with diskcopy a: and diskcopy a: b:
d) I have an USB diskette drive and a regular 3,5 inch drive, both are old, same with the 3,5 inch 720k and 1440k diskettes. So a lot of things can happen. But my experience was that the same diskette sometimes exited with an error, sometimes it worked fine, often /u helped then. So my question:
Is format "hardened"? Or do you need more tests?
e) As I am in contact with Mateusz Viste: His edrdos kernel is nice, but there is a small problem:
aa) I boot from his edrdos diskette, enter format a: (format b: also always gave error messages)
bb) then I change the diskette
cc) format starts, asks for label (what is the actual situation of label, reason: chkdsk, dosfsck etc. have different consequences)
dd) format works (or error message)
ee) at the end it misses the command.com that is on the edrdos diskette (of course) - and I have no chance to come there.
Is the message missing "command.com" a correct behaviour, or should it stay resident? Or should format give a message: "Please insert the diskette with command.com" - and maybe search itself for it?

Thx for reading.

[boeckmann]

ee) is actually correct behaviour, as SvarCOM tries to reload itself from A:. It cannot do this because the disk containing command.com is not there anymore. Accorting to @mateuszviste it even retries to reload after keypress, but does not mention so. This will be improved. The issue for that is SvarDOS/bugz#122

[PerditionC]

a) Can you add the german translation when it is ready

Yes, please send it to me or post a Pull Request or send it to the list -- see below

as I have the feeling that a lot of german text is bad or misunderstandable. Especial with variables, as english grammar differs from other grammars, sometimes the first english words appear at the end of the german (maybe turkish and french version too) text, so it is helpful to see the text at work - this may cause problems with variables.

This is a concern of mine, which is largely why I started this discussion and am trying to release test releases as often as I can for testing updated translations

b) I noticed that actually the en/fr/tr text is inside of the .exe file. Will this stay or will you work with format.de/en/fr/tr files at C:\freedos\nls as most other programmers do? This makes it easier to test format text and to see the result of text modifications - and the .exe stays small.

Yes to both. By default, I plan to release two version, one exe without the languages files appended to the exe and depending on size/how many/etc. I would like to release a version with languages included. Both versions will use additional languages message sets that can be found in a user's NLSPATH. However, these are not plain text messages but "compiled" message sets. [compiled in the sense the text source is converted to a binary file where the strings are already parsed and escape codes converted along with some meta data and then saved in a binary format]. A single message catalog can be appended to format.exe by just copying to the end of the file - kittenc (or its in progress updated tool msgbuild) can create a message catalog with multiple language message sets, which is why you see multiple languages in the exe.

To test, you will need to use kittenc to get the binary message set, but otherwise works similar to other programs that use kitten/catgets.

c) One more thing: Till today I saw no working "format b:" There were always error messages. I think format a: and format b: should work. I already tested it fine with diskcopy a: and diskcopy a: b:

format a: and format b: should both work, if they are not, please add an issue with steps to reproduce (or describing your setup, e.g. 1.44MB disk in 2.8MB drive, or virtual 720KB floppy with VirtualBox, ...). The current build works fine in my test setup, but format diverges into 2 code paths, one for floppies and one for hard drives so there could still be some work/tweaking needed.

d) I have an USB diskette drive and a regular 3,5 inch drive, both are old, same with the 3,5 inch 720k and 1440k diskettes. So a lot of things can happen. But my experience was that the same diskette sometimes exited with an error, sometimes it worked fine, often /u helped then. So my question:
Is format "hardened"? Or do you need more tests?

Format does a lot of checking for the expected conditions, however, there are quite a few different code paths that floppy formatting takes depending on options and existing format - safe/quick/unconditional/... and I can't say there aren't cases where it may just need to retry for success but fails instead. I would not say it is not hardened, but cautious. The tests probably can be improved, but I'm not planning for any.

[fritzmueller]

format.zip
Enclosed the german trial version of format.de, I am sure some things still have to be fixed.
Referring to format a: and format b: Have a look at: SvarDOS/bugz#121 - it seems that the SvarDOS group was able to reproduce the bug.

[mateuszviste]

Yes to both. By default, I plan to release two version, one exe without the languages files appended to the exe and depending on size/how many/etc.

Just a suggestion: using SvarLANG it would actually not be required to ship two distinct versions, because the EN string would be hardcoded into the executables, and all other messages would be in the associated FORMAT.LNG file. If user does not need the extra languages, then the FORMAT.LNG can be simply deleted and FORMAT would become EN-only. SvarLANG is the NLS library used by Free-FDISK, and also all the SvarDOS-specific tools.

format a: and format b: should both work

This problem is slightly deeper than it appears. @fritzmueller uses B: on a single-diskette system that boots from A:. In such case, it would be expected that DOS asks first to insert a floppy into "B:", and then - once FORMAT is over - ask to insert the OS diskette back into "A:". This does not happen in our tests, but we are unsure yet exactly why. Investigations are ongoing in SvarDOS/bugz#121.

[fritzmueller]

OK, now two picture series are uploaded on my website: Svardos www.bootablecd.de/SM-G990B-Mateusz.7z and FreeDOS: SM-G990B-K-J-Davis3.7z
You can see that drive B: never works while formatting.
I noticed that you can format the diskette where you booted from - no basic problem, but there should be a warning that source diskette and the diskette to format have the same serial number - do you really want to format?
The german help file is above this message, so please could please send me an exe file with german support?
fritz.mueller - NEAR - mail.com
Thx

[fritzmueller]

format-UTF8-de.txt
Maybe you got the UTF-8 update of format.de twice, but I am not yet familiar with these pull requests. You noticed the text above with the two hyperlinks to the screenshots?

[fritzmueller]

Hi, I just noticed a strange behaviour of format 0.92a: I added german NLS - and it showed english language. Then I tested french and turkish - and they worked (with cp restrictions, but they worked). Then i ran copy format.tr format.de (and later format.fr format.de) - and the turkish / french language did not appear, only english. So it seems not to be a mistake with my format.de but in format ? As tr and fr also did not work after renaming it should not be a UTF-8 problem. Strange.   Could you pleas test this.   Thx   Willi     Sent: Wednesday, September 18, 2024 at 11:40 PM From: "Kenneth J Davis" ***@***.***> To: "FDOS/format" ***@***.***> Cc: "fritzmueller" ***@***.***>, "Comment" ***@***.***> Subject: Re: [FDOS/format] Translations (Discussion #10)   a) Can you add the german translation when it is ready Yes, please send it to me or post a Pull Request or send it to the list -- see below as I have the feeling that a lot of german text is bad or misunderstandable. Especial with variables, as english grammar differs from other grammars, sometimes the first english words appear at the end of the german (maybe turkish and french version too) text, so it is helpful to see the text at work - this may cause problems with variables. This is a concern of mine, which is largely why I started this discussion and am trying to release test releases as often as I can for testing updated translations b) I noticed that actually the en/fr/tr text is inside of the .exe file. Will this stay or will you work with format.de/en/fr/tr files at C:\freedos\nls as most other programmers do? This makes it easier to test format text and to see the result of text modifications - and the .exe stays small. Yes to both. By default, I plan to release two version, one exe without the languages files appended to the exe and depending on size/how many/etc. I would like to release a version with languages included. Both versions will use additional languages message sets that can be found in a user's NLSPATH. However, these are not plain text messages but "compiled" message sets. [compiled in the sense the text source is converted to a binary file where the strings are already parsed and escape codes converted along with some meta data and then saved in a binary format]. A single message catalog can be appended to format.exe by just copying to the end of the file - kittenc (or its in progress updated tool msgbuild) can create a message catalog with multiple language message sets, which is why you see multiple languages in the exe. To test, you will need to use kittenc to get the binary message set, but otherwise works similar to other programs that use kitten/catgets. c) One more thing: Till today I saw no working "format b:" There were always error messages. I think format a: and format b: should work. I already tested it fine with diskcopy a: and diskcopy a: b: format a: and format b: should both work, if they are not, please add an issue with steps to reproduce (or describing your setup, e.g. 1.44MB disk in 2.8MB drive, or virtual 720KB floppy with VirtualBox, ...). The current build works fine in my test setup, but format diverges into 2 code paths, one for floppies and one for hard drives so there could still be some work/tweaking needed. d) I have an USB diskette drive and a regular 3,5 inch drive, both are old, same with the 3,5 inch 720k and 1440k diskettes. So a lot of things can happen. But my experience was that the same diskette sometimes exited with an error, sometimes it worked fine, often /u helped then. So my question: Is format "hardened"? Or do you need more tests? Format does a lot of checking for the expected conditions, however, there are quite a few different code paths that floppy formatting takes depending on options and existing format - safe/quick/unconditional/... and I can't say there aren't cases where it may just need to retry for success but fails instead. I would not say it is not hardened, but cautious. The tests probably can be improved, but I'm not planning for any. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>