Overhaul localization with external INI language files

[MinDeaDBlood]

Hi, I have rebuilt and adapted this localization work on top of your latest dt_prerel_2681 commits.

What changed

• Reworked the application localization system to load translated values from external INI files.
• Added runtime discovery of language files from the language directory, including files added after DISMTools has been installed.
• Kept the six current languages in the same external format.
• Set the first use setup wizard to start in English, matching the original default behavior.
• Adapted your latest About dialog anniversary and copyright changes to the INI system.

Designer safety

Following your review, all generated Designer.vb and .resx files now match the current base branch exactly. They keep their normal English design-time text. Translations are applied programmatically during OnLoad from ordinary VB source files, using the same external INI files. No localization code runs from the generated designer files.

Validation and error handling

The localization system includes strict validation and clear diagnostics. Before a language is applied, DISMTools checks the INI file for missing required keys, invalid numbered placeholders, and syntax errors. An invalid language file is not applied, and the previous language remains active.

If code requests a missing key at runtime, a dedicated localization exception identifies the language file, section, key, full key, and source location. It also explains which entry needs to be added. A detailed validation report is saved under logs\localization. The program does not silently fall back to another translation.

Scope

Apart from the compilation correction described below, all changes in this PR belong to the localization overhaul. Other user-reported fixes discovered during testing have been intentionally excluded. Those can be submitted later as focused commits or separate PRs if you want them.

Compilation correction

There is one small unrelated correction in ProgressPanel.vb. An End Select statement had been appended to the DISM command line, which produced invalid VB code and prevented the project from compiling in our build. I separated it onto its own line in commit 3af9310.

This correction is isolated in its own commit. If you prefer to keep the original code, let me know and I will remove that single commit from the PR without affecting the localization changes.

Checks

• The branch is based directly on the latest dt_prerel_2681 commit available when this update was prepared.
• All six INI files contain the same 5,938 localization keys, with no duplicates or missing numbered placeholders.
• All 2,814 form localization calls were moved from 142 generated designer files into ordinary runtime source files.
• The generated Designer.vb and .resx files have no differences from the current base branch.
• The latest About dialog anniversary text is present in every language file.
• No fork-specific build workflow or release packaging changes are included.
• git diff --check reports no errors.

[CodingWonders]

Do not touch the designer code. To switch languages, stick with programmatically handling the translations.

1. The designer may fail to render the form, or
2. Stuff may be messed up in the designer

[CodingWonders]

Make sure to test all changes. When I tested your code, I ran into unhandled index out of bounds exceptions.

@MinDeaDBlood, I would like you to not use AI for testing this. Grab your mouse and keyboard and start doing things.

[MinDeaDBlood]

Make sure to test all changes. When I tested your code, I ran into unhandled index out of bounds exceptions.

@MinDeaDBlood, I would like you to not use AI for testing this. Grab your mouse and keyboard and start doing things.

I am not a professional, and I run everything either via GitHub Actions or locally. I restored the build file that you deleted, and everything built and ran successfully with no errors in the log. I do not use any other environments, which is why everything works fine on my end. If you encounter any issues, please send the logs along with details on where and when they occur.

[MinDeaDBlood]

Make sure to test all changes. When I tested your code, I ran into unhandled index out of bounds exceptions.

@MinDeaDBlood, I would like you to not use AI for testing this. Grab your mouse and keyboard and start doing things.

Therefore, I suggest we change the tone of our communication: either send me the error logs showing where and when they occur, or make the fixes yourself. I have done all the work that you wouldn't take on. I no longer have time for groundless accusations. I did the job to the best of my ability. It works, it doesn't lag, and it doesn't slow down during operation: that is my criterion of quality.

[CodingWonders]

Therefore, I suggest we change the tone of our communication: either send me the error logs showing where and when they occur, or make the fixes yourself. I have done all the work that you wouldn't take on. I no longer have time for groundless accusations. I did the job to the best of my ability. It works, it doesn't lag, and it doesn't slow down during operation: that is my criterion of quality.

I am not accusing you of anything, so there are no "groundless accusations". All I'm asking is for you to test every single action in the program in all of its languages, plus the on-the-fly switching of languages, just to test how well your overhauled language system works. Yes, this can take hours, but I would prefer that over saying "it works, it doesn't lag, and it doesn't slow down".

So, you could say that your criterion of quality and my criterion of quality are different. If I have to test something, I test it, no matter how many builds or runs I do. If I have to hook up a debugger, I'll do it. However, speed and the "it just works" factor aren't the only things in my QA tests.

Also, the "make the fixes yourself" statement. I'm already too busy adding new and innovative features, and maintaining several repos at once, to go look at someone else's code that, in my testing standards, can fail. Besides, that isn't my code, but someone else's, so I only really need to review it so I can accept the thing. But, why do I need to check out your branch to hook up a debugger, patch the code myself, and commit the fixes? Aren't you supposed to do such things, as the PR author? I'm just asking.

The logs. If you run into the issues that I had described earlier (those index out of bounds exceptions), then you already have them and don't have to ask me to provide such logs.

Now, if the reason you're responding like that is because I'm nitpicky over the fact that you vibed the thing, fair point. Even a year after vibe coding became what it became, I'm still not into that sort of thing. But, does that make me anti-AI? No, because it does have its use cases. What I'm not for when it comes to changes made with AI is for stuff to be made with AI with no manual testing from the PR author. I'm kindly asking you to provide that manual testing bit, so that the PR becomes more likely to be merged after having been determined that it doesn't compromise the project's quality.

[MinDeaDBlood]

Therefore, I suggest we change the tone of our communication: either send me the error logs showing where and when they occur, or make the fixes yourself. I have done all the work that you wouldn't take on. I no longer have time for groundless accusations. I did the job to the best of my ability. It works, it doesn't lag, and it doesn't slow down during operation: that is my criterion of quality.

I am not accusing you of anything, so there are no "groundless accusations". All I'm asking is for you to test every single action in the program in all of its languages, plus the on-the-fly switching of languages, just to test how well your overhauled language system works. Yes, this can take hours, but I would prefer that over saying "it works, it doesn't lag, and it doesn't slow down".

So, you could say that your criterion of quality and my criterion of quality are different. If I have to test something, I test it, no matter how many builds or runs I do. If I have to hook up a debugger, I'll do it. However, speed and the "it just works" factor aren't the only things in my QA tests.

Also, the "make the fixes yourself" statement. I'm already too busy adding new and innovative features, and maintaining several repos at once, to go look at someone else's code that, in my testing standards, can fail. Besides, that isn't my code, but someone else's, so I only really need to review it so I can accept the thing. But, why do I need to check out your branch to hook up a debugger, patch the code myself, and commit the fixes? Aren't you supposed to do such things, as the PR author? I'm just asking.

The logs. If you run into the issues that I had described earlier (those index out of bounds exceptions), then you already have them and don't have to ask me to provide such logs.

Now, if the reason you're responding like that is because I'm nitpicky over the fact that you vibed the thing, fair point. Even a year after vibe coding became what it became, I'm still not into that sort of thing. But, does that make me anti-AI? No, because it does have its use cases. What I'm not for when it comes to changes made with AI is for stuff to be made with AI with no manual testing from the PR author. I'm kindly asking you to provide that manual testing bit, so that the PR becomes more likely to be merged after having been determined that it doesn't compromise the project's quality.

The thing is, I’m just a hobbyist. When a project catches my interest, I write the code directly without using any specialized IDEs or compilers. I usually ask AI to submit pull requests with descriptions, or to process my voice recordings and translate them into proper English, since I am not a native speaker.I will install Visual Studio and look into it. Since I am a hobbyist, I have never used it before. It seems our misunderstanding happened because you can see exceptions in Visual Studio that simply don’t show up through other, simpler coding methods.

[MinDeaDBlood]

By the way, writing long messages is just my personal communication style - it’s not AI writing all of this.

[CodingWonders]

I’m just a hobbyist. When a project catches my interest, I write the code directly without using any specialized IDEs or compilers. I usually ask AI to submit pull requests with descriptions, or to process my voice recordings and translate them into proper English, since I am not a native speaker.I will install Visual Studio and look into it. Since I am a hobbyist, I have never used it before. It seems our misunderstanding happened because you can see exceptions in Visual Studio that simply don’t show up through other, simpler coding methods.

So am I, yet I use Visual Studio. The fact that you may be a hobbyist doesn't mean you don't have to use Visual Studio, because you must. Blindly relying on what AI tells you is not the way to write code, let alone vibe. You must test it and, for a 17k+ LOC diff (additions - removals), it can take hours.

Also, fixed the merge conflicts after rebasing your PR on a newer branch. That's all I have to do, as a maintainer and owner. You have a long time to work on this change.

[MinDeaDBlood]

I’m just a hobbyist. When a project catches my interest, I write the code directly without using any specialized IDEs or compilers. I usually ask AI to submit pull requests with descriptions, or to process my voice recordings and translate them into proper English, since I am not a native speaker.I will install Visual Studio and look into it. Since I am a hobbyist, I have never used it before. It seems our misunderstanding happened because you can see exceptions in Visual Studio that simply don’t show up through other, simpler coding methods.

So am I, yet I use Visual Studio. The fact that you may be a hobbyist doesn't mean you don't have to use Visual Studio, because you must. Blindly relying on what AI tells you is not the way to write code, let alone vibe. You must test it and, for a 17k+ LOC diff (additions - removals), it can take hours.

Also, fixed the merge conflicts after rebasing your PR on a newer branch. That's all I have to do, as a maintainer and owner. You have a long time to work on this change.

I opened up Visual Studio and the only issue I found was with Columns(5) in MountedImgMgr.vb

[CodingWonders]

So, you know the drill, right? Find an issue in the code, patch it, commit it. Rinse and repeat, until we have something perfect.