You've forgotten to write the backslashes into the path as well.
I click OK again, and the program starts, but shows somewhere labels like 'Ask-Title' or 'Yes-Title'.
I save them in ANSI (on my machine it's Windows Central European, windows-1250), and no problem occurs, the language-selecting menu appears correctly. As I know, Unicode or UTF-8 have been created specially to cope with these international coding problems. German Unicode and Hungarian Unicode should be the same. But what if some coding-conversion is done by Java automatically? I don't know Java at all, it's your profession. But, at the moment, it's the only one reason I can think of. Maybe the problem is that Java wants to convert characters on my machine into Central European Windows (windows-1250) or into Central European ISO (iso-8859-2), while on your machine they are converted into Western European Windows (windows-1252) or into Western European ISO (iso-8859-1). Of course, I just guess. The problem can be absolutely different, it's just one slight idea.
Meanwhile an other problem has occured: sometimes when I start the program, it says: 'No languages found in folder c:lang' (and sometimes it tries other invalid paths, too). Why does MDSC want to open the language file from C:\, when the program's root directory is D:\Programs\MDSCv0.2.0\? And, at the same time, pictures on the buttons are also not willing to load. Strange.
But let's go on to exporting and importing, where the problem is the contrary.
And it writes more lines in the dialogue, telling exactly the same with other MyDefrag versions down to 4.2.7.
The script is exported in Unicode. But if I save it in ANSI, it is sucessfully imported. Or, almost sucessfully. Special language characters, like á, é letters and so on, don't appear correctly, just white squares. However, if I open the scriptfile itself (with Notepad), they are all OK. And there's the same problem with the translated language files.
So, it's a good idea to keep text files, such as scripts and language files, coded in Unicode - then they can be used worldwide, and there won't be any problems with the translations. The only thing to do is to make the program able to handle Unicode files. You've thought that it does handle well, but I must aware you: it doesn't, at least in other countries.
Could you upload the converted file with just a few of these special characters, so that I can take a look at it if I have the same problem.
But only if the files are coded in Unicode. If they are in ANSI, special characters don't appear, just white squares. (But even in this case, error message doesn't appear.)