DISMTools 0.8 Preview 6 and 0.7.3 Update 3 are now available for download and installation. They are also available on WinGet. Be sure to try these and report feedback. Update 3 is the final update to DISMTools 0.7.3, and the next stable version will be 0.8.
Will there ever be a German edition of this? I've already asked for it; it would be fantastic to make that happen. Thx in effort
DISMTools 0.8 Preview 8 is now available for you to use. The update system will pick it up and install it for you. It will also be available on WinGet. Since this is the final preview release of DISMTools 0.8, report feedback! The preview window will close next week, when version 0.8 is released as a stable version.
The stable version of DISMTools 0.8 is now available for download and installation. It will also be available on WinGet.
Hi. I’ve built a proper localization system, so now you can add and edit languages via ini files in localization\languages. I can send you the source code in a zip archive or push it to GitHub. I’ve tested the installation and launch. Everything opens fine and languages switch correctly, but I haven't tested working with images yet.
I would like you to make a pull request targeting the latest development branch. Now, you will have to wait as that change is simply too big to look at and pull at this point in the 0.8.1 Preview 1 development pipeline. Wait until Preview 2 starts development, then I'll be able to test it properly. Also, on GitHub I can mention you more easily.
Kept the existing language engine. The main DISMTools UI uses LocalizationService. Internally, it reads UTF 8 INI files through the existing INI File Parser library, specifically FileIniDataParser from ini-parser 2.5.2. The main application language files are stored here: Localization\languages These are the current main INI files: en-US.ini es-ES.ini fr-FR.ini it-IT.ini pt-PT.ini This localization layer is used by the main DISMTools application, including the first run Initial Setup Wizard, the main window, the Options window, and the normal application forms. At runtime the UI should not read user visible strings directly from hardcoded text anymore. It asks LocalizationService for a key, for example: LocalizationService.T("SomeWindow.SomeControl.Text") Then LocalizationService returns the value from the currently selected language file. HotInstall is a separate helper, so it has its own small INI language loader instead of using the main application LocalizationService directly. Its language files are stored here: Helpers\extps1\PE_Helper\tools\HotInstall\Installer\Languages The current HotInstall INI files are: lang_en.ini lang_es.ini lang_fr.ini lang_it.ini lang_pt.ini These are also INI files and are also read through FileIniDataParser. The Inno Setup installer is a separate case. It runs before DISMTools starts, so it cannot directly use the application LocalizationService or the main INI files from Localization\languages. Inno Setup uses its own native .isl language files. The installer language files are stored here: Installer\Languages The current local installer language files are: French.isl German.isl Italian.isl Portuguese.isl Spanish.isl English is currently connected in Installer\dt.iss through the default Inno Setup language file: Name: "en"; MessagesFile: "compiler: Default.isl" So, at the moment, English for the installer comes from Inno Setup Default.isl, while the other installer languages come from Installer\Languages. Editing existing translations is easy. For the main application, you open the corresponding INI file under Localization\languages and change the value for the needed key. For HotInstall, you edit its INI file in its own Languages folder. For the Inno Setup installer, you edit the corresponding .isl file in Installer\Languages. Adding a completely new language is straightforward, but it requires a few coordinated changes. You need to add the new main application INI file with the same keys, add the language metadata, add the HotInstall INI file, add the Inno Setup .isl file if the installer should support that language too, update the language selector mappings, include the files in the build, and run the localization validation script.
If you need to change or add to the description, you just need to change the text that comes after Load.Button2_Text= Load.Button2_Text=Select all
DISMTools 0.8.1 Preview 1 is now available, and one of its new features is a new concept: the Starter Script Library. If you have a starter script that can help anyone in the world, there's no better place to upload it to than the Starter Script Library. Using the Starter Script Editor and a GitHub API key, you are off to uploading scripts in a short time: Scripts in the Library will show up here when you browse for starter scripts: A really cool thing is that, if a starter script from the library could become a great addition to DISMTools, it will be added to the standard collection. When that happens, the script author will be mentioned. Let's see what you come up with! Anyway, 0.8.1 Preview 1 will also be available on WinGet.
Hi everyone, The Windows Guy and nekro666 Suggestion for DISMTools Localization: Moving from INI to JSON (with automated PS migration script) First of all, congratulations to The Windows Guy and nekro666 for the amazing work on DISMTools. The project has grown beautifully, and the localization system implemented so far has been a great step forward for making the tool accessible globally. However, as the project expands, I would like to propose a structural improvement regarding the language files: moving from the current .ini format to a modern .json format. While the current INI system works, it has some limitations when handling complex, nested language keys. Here is why switching to JSON would benefit the project long-term: 1. True Hierarchical Structure Currently, the INI file tries to simulate a hierarchy using section names and dotted keys (e.g., PrimarySuffix.Required or Install.Stub.Package.Item). JSON natively supports nested objects, creating a clean, logical "tree" structure. This makes the files much easier to read, maintain, and extend for translators. 2. Native and Cleaner PowerShell Integration PowerShell handles JSON brilliantly with a single native cmdlet (ConvertFrom-Json), turning the file directly into a structured custom object in memory. Parsing INI files, on the other hand, often requires complex regex work or older Win32 API workarounds. Furthermore, structured JSON eliminates the need for manual newline workarounds like {crlf;}. 3. Standards & Encoding The JSON standard (RFC 8259) implicitly uses UTF-8, which ensures full cross-platform compatibility. For the Windows/PowerShell environment, a clean UTF-8 (with or without BOM depending on the exact .NET targeting) ensures that special localized characters (like Hungarian double acutes ő, ű, Cyrillic, or Asian characters) never break or get corrupted. No Translation Work Will Be Lost (Automated Migration) To prove that this transition can be seamless, I have written a PowerShell migration script with a simple GUI. This script automatically converts any existing language .ini file into a clean, optimized, and fully structured .json file in seconds, preserving the exact section order and handling dotted key hierarchies without any data loss. (You can find the standalone script attached below/in the code block). I believe making this shift now, while the project is still in its active development phase, would save a lot of headaches in the future and elevate the internal architecture of DISMTools. What do you guys think? I'd love to hear your thoughts, especially from The Windows Guy and nekro666! Best regards, Fowler.
Hi Fowler, Thank you for the suggestion and for taking the time to write the converter script. I understand the reasoning behind using JSON, especially the idea of having a more explicit nested structure. However, after looking at how the current localization system is implemented in DISMTools, I am not convinced that moving from INI to JSON would give us enough practical benefit right now. The current localization layer is already centralized through LocalizationService, ForSection, T, TUpper, and the legacy helper methods. The application code does not work directly with the language file format in most places; it asks the localization service for a section/key pair. In other words, the runtime localization model is already key-based. Moving the storage format from INI to JSON would not change what the application can localize - it would mostly change how the same data is stored and loaded. The current INI files are also already read explicitly as UTF-8 in LocalizationService, so the encoding argument is not a strong reason to migrate in this project. Unicode characters such as Cyrillic or accented European characters are not inherently a problem for the current implementation. Also, this would not be just a simple file conversion. To actually use JSON in DISMTools, we would have to rewrite or replace the current localization backend/translation engine that loads, stores, resolves, and validates language data. At the moment, the INI system already works, supports dynamic language discovery, keeps the language files consistent, and has validation tooling around it. Because of that, I do not think replacing it with JSON is justified unless we have a concrete problem that the current INI format cannot solve. So my position would be: JSON may be worth considering in the future if we need a richer localization format, but I would not migrate the existing system only for structural/aesthetic reasons. Right now it would add migration work and maintenance risk without improving the actual localization capabilities of the application.
When will a German translation finally be released? I certainly think it has a right to exist. Thank you for your attention and for considering going ahead with it.
I'm still waiting for changes to the translation system to pop up in the GitHub repository. You will have to wait until then.