French translation

[boeckmann]

Hello @cardpuncher, I have bundled a translation package containing everything needed to generate and test the FDISK translation for french. Please see https://nextcloud.iww.rwth-aachen.de/index.php/s/w8nmaH8gMB9H3Rj

There is a HowTo.md describing the process. You can view it in the browser by clicking on the file. Would be great if you give me feedback so I can improve the howto for the other translators.

You may download all files as a ZIP archive.

Thanks for helping!

[cardpuncher]

Hey Bernd,

I must be doing something really wrong because I can't get FDISK to display another language than English. set lang=fr or any other language code didn't make any difference. I modified the regen.bat file to include French & Turkish, ran it then launched FDISK.EXE only to get it in English. The screenshot below should give an idea of what I did:

[boeckmann]

Looks good @cardpuncher . I can not detect an error in the screenshot. It may be that your .EXE is too old. With the french translation you sent me today afternoon, the language buffer hat to be enlarged. This is because the french translation is bigger in size than the other ones (see the values in your screenshot).

Until now, the program silently failed when running short of buffer space. I catched this case with the new binary, and an error is thrown. But I am confident that the new EXE will work. If not, the error must be somewhere else.

https://nextcloud.iww.rwth-aachen.de/index.php/s/w8nmaH8gMB9H3Rj

[boeckmann]

The thing is, that the translations may only get 5% bigger, until the EXE has to be rebuilt. But I may increase this during development to a more generous value.

[mateuszviste]

the new fdisk.lng must be copied to %NLSPATH% for SvarLANG to find & load it

[mateuszviste]

The thing is, that the translations may only get 5% bigger, until the EXE has to be rebuilt. But I may increase this during development to a more generous value.

This is not exactly correct, albeit it's probably just a wording issue. the limitation is that a translation can grow at most to "current biggest language + 5%".

Example: if the biggest language is french and FR translations are 10KB in size, then ANY other translation may grow at most to 10.5 KB. Let's say that PL is currently 2 KB - in regard to the above it can grow 5x without needing any code rebuild. I hope it's clear(er).

[boeckmann]

the new fdisk.lng must be copied to %NLSPATH% for SvarLANG to find & load it

@cardpuncher It may be that the NLSPATH variable is not set at all. Then fdisk will find the FDISK.LNG in the current working dir, which is the dir of FDISK.EXE in case of the translation package you got. You may unset the NLSPATH variable, then you do not have to copy it to the NLSPATH.

[cardpuncher]

On 8.07.2023 23:13, Mateusz Viste wrote:

the new fdisk.lng must be copied to %NLSPATH% for SvarLANG to find & load it

Okay, that worked, thank you Mateusz. Maybe that should be added to the How-to, also explaining that %NLSPATH% is C:\FREEDOS\NLS by default on FreeDOS to make things easier for translators.

[boeckmann]

I made an addition to the program. The .LNG file is now searched in the program directory first. The reason is the following: When we start to distribute the .LNG file with FreeDOS, translators should not have to overwrite the existing FreeDOS installation files, but instead can try their changes locally.

It is implemented via ee9fd13f3e79201a71ada0c0fc7ca998884c6e34. I updated the translation package accordingly with the new binary.

[boeckmann]

There was an error in the last binary. Updated it again, sorry.

[mateuszviste]

I made an addition to the program. The .LNG file is now searched in the program directory first.

This is certainly more convenient for translators, but the code will be shipped to all users. I am not convinced it is a good thing to have in all binaries and (potentially) in all programs using SvarLANG.

I think it would be better that svarlang proposes a few different functions:

svarlang_autoload_nlspath() -> looks for LNG in %NLSPATH% (used by all SvarDOS tools)

svarlang_autoload_exepath() -> looks for LNG in executable's directory (used by "normal" programs)

svarlang_autoload() -> calls the two functions above (used by FDISK)

At the same time it is worth noting that translators are probably used to overwriting translations in NLSPATH anyway since that is how it works with the majority of FreeDOS tools anyway, as the kitten lib looks in NLSPATH only.

about the looking-in-prog-dir:

this should definitely look inside the program's directory ("directory where the executable file is"), and not the current directory, as the second option might be unpredictable or even dangerous.

char progpath[_MAX_PATH] seems overkill. the program's name is already in the program's environment, so it would be better (faster, smaller) to leverage that, just changing the EXE or COM extension by LNG (and reverting it back once the work is done).

[boeckmann]

I think it would be better that svarlang proposes a few different functions:

svarlang_autoload_nlspath() -> looks for LNG in %NLSPATH% (used by all SvarDOS tools)

svarlang_autoload_exepath() -> looks for LNG in executable's directory (used by "normal" programs)

svarlang_autoload() -> calls the two functions above (used by FDISK)

Sounds like a clean solution!

about the looking-in-prog-dir:

this should definitely look inside the program's directory ("directory where the executable file is"), and not the current directory, as the second option might be unpredictable or even dangerous.

Yes! The current directory search is triggered if the NLSPATH variable is empty. Was not sure if it was intended behaviour or a side effect of the algorithm. But I agree that this should be avoided.

char progpath[_MAX_PATH] seems overkill. the program's name is already in the program's environment, so it would be better (faster, smaller) to leverage that, just changing the EXE or COM extension by LNG (and reverting it back once the work is done).

There is also the path that gets separated. And the extension may not be there. I am unsure that the increased complexity of the algorithm is worth the benefit.

[mateuszviste]

There is also the path that gets separated. And the extension may not be there. I am unsure that the increased complexity of the algorithm is worth the benefit.

The extension must be there, since otherwise the file wouldn't be executable in the first place. And the path is already there as well, no need to separate it.

Basically at ENVIRON + strlen(ENVIRON) + 1 you get a word that is either 1 or 0. if it is anything else than 1, abort (older DOSes), otherwise look a the string that follows it. Jump to the end of the string - 3, remember the three characters there, replace them by LNG and give this to svarlang for loading. Then revert the 3 letters to whatever it was before (in practice - EXE or COM).

Look here, function set_comspec_to_self() : http://svn.svardos.org/filedetails.php?repname=SvarDOS&path=%2Fsvarcom%2Ftrunk%2Fcommand.c

[boeckmann]

I tried to stay compatible with svarlang_load without changing it. There was no other way than splitting the path component and provide that to svarlang_load as nlspath.

[mateuszviste]

I tried to stay compatible with svarlang_load without changing it. There was no other way than splitting the path component and provide that to svarlang_load as nlspath.

I understand now. I think svarlang_load() should be simplified to svarlang_load(const char fname, const char lang), and the path-gluing business be left to svarlang_autoload_nlspath() since it is the scenario case that requires such work - or even better svarlang_autload_inpath() (and let the program use whatever path it likes). I hope to look into that this evening. It's good to make SvarLANG's API as optimal as possible. So far only few software use it is still a good time to make such changes without worrying about backward compatibility.

[boeckmann]

Perfect, I already implemented the svarlang_autoload_nlspath and svarlang_autoload_exepath. But changing svarlang_load the way you described makes sense to me.

Perhaps also a function svarlang_get_lang should be implemented, that returns the language identifier, or EN if not specified by the environment variable.

[boeckmann]

Hi! Is there a common abbreviation for Utilisation? Makes aligning the tables a little bit hard. Otherwise, french translation looks good!

Question out of interest: Is it common in France to put a space in front of the colons?

[cardpuncher]

On 14.07.2023 17:39, Bernd Böckmann wrote:

Hi! Is there a common abbreviation for /Utilisation/? Makes aligning the tables a little bit hard. Otherwise, french translation looks good!

Thanks, that's good to hear. "Utilisation" is, IMHO, the best word but it could be replaced by "Emploi" if really necessary. Would you like me to edit the French translation?

Question out of interest: Is it common in France to put a space in front of the colons?

Yes, that's a rule of the French typography. Ideally it has to be a narrow non breaking space, but usually people just use a non breaking space or a simply a space. For more information on this, you can see https://en.wikipedia.org/wiki/Non-breaking_space#Width_variation which states: "It is also required for big punctuation in French where it is called espace fine insécable and sometimes inaccurately referred to as "double punctuation" (before ;, ?, !, », › and after «, ‹; today often also before :)".

[boeckmann]

Thanks, that's good to hear. "Utilisation" is, IMHO, the best word but it could be replaced by "Emploi" if really necessary. Would you like me to edit the French translation?

If time permits, would be great. In case you do it, please use the latest version of the file from this repository. Otherwise I will do it before end of the month, so that this can all go into the next FreeDOS interim build T2308.

[mateuszviste]

Instead of the long "utilisation" I would suggest the somewhat shorter "utilisé".

I confirm that the annoying space before colon is lawful in France.

[cardpuncher]

Argh, indeed "Utilisé" is better than "Emploi", I should have seen your message before sending the PR...

I also noticed a "Mbytes" word that is not translatable, please see the screenshot below:

[boeckmann]

I also noticed a "Mbytes" word that is not translatable

Thanks, did not notice that one. I made it translatable and updated the translations accordingly!