An MUI file is just a PE file (DLLs and EXEs are PE files) that contains resources... at least as far as my program is concerned. (Everything else in the file is ignored.) It's the standard method for localization in Windows; it doesn't really make sense for me to create my own (inevitably buggy) file format and parser from scratch just for this.
The MUI file needs to be in a subfolder with the same name prefix as the program followed by .mui, so something like en-US\SwiftSearch.exe.mui.
To create an MUI file, "unofficially" you could just use a program like Resource Hacker to save the executable's String Table to a .res file (to remove the embedded code etc.), open that .res file again and save it as a .dll file, then rename that .dll file to a .exe.mui file, like SwiftSearch.exe.mui. Then just put that in the right subfolder (e.g. en-US).
Now you can open it again in Resource Hacker and modify it to your heart's content. Just make sure to change the language ID as appropriate (it should already be 1033 for English).
If it's in the right folder, my program will try to use it before falling back to the English text. You can make sure that it's working by deleting the String Table in the executable so that the strings will be empty if the MUI file isn't present.
(Let me know if this doesn't work -- I haven't tested it since it's a bit difficult to test on an English system.)
If you wanted to create the MUI file "officially", you could do something like this:
Get MUIRCT (it's in the Windows SDK).
Create a subfolder for the locale of your choice, like en-US.
Create an appropriate XML configuration file, e.g. create MUIConfig.xml and copy-paste this inside it: <?xml version="1.0" encoding="utf-8"?><localization><resources><win32Resources fileType="Application"><localizedResources><resourceType typeNameId="#6" /></localizedResources></win32Resources></resources></localization>
Run MUIRCT appropriately, e.g. by running it as follows: muirct -q "MUIConfig.xml" -x en-US SwiftSearch.exe SwiftSearch.ln.exe en-US\SwiftSearch.exe.mui
Note that MUIRCT is located in the Windows SDK folder, such as %ProgramFiles(x86)%\Windows Kits\8.1\bin\x64\muirct.exe
Delete the .ln (language-neutral) executable; it's basically the original executable with the resources removed (and some minor stuff added).
Does this make sense?
Also, oops, I just realized the dialog resources also have embedded text that I don't load dynamically; thanks for mentiong that! I just fixed this in my code, so you should see this the next time I release a new version. (It's not worth making a new release just for this.)
Last edit: - 2018-04-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By the way, I think it might also be possible to avoid MUI files by just adding a string table to the executable with the correct language ID (without needing to modify the existing one). Microsoft seems to suggest this should "just work". The benefit is that you only have that one executable, so it's nice if you don't want to give people multiple files. The downside is you'll have to copy around the resources every time there's a new version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, I'll do it in the "unofficial" although approved way hehe.
I've tested this now making the "es-VE" folder, works, although yes, is not loading the strings from Dialog and Menu.
I'm not sure about how this will works with the other spanish "variants" like es-AR, es-MX, es-ES, etc. I guess this have some simple solution but I don't know until now.
Also I guess the same apply for other languagues with your own variants.
I'm agree with you in use the standard method for localization in Windows is the best way, but I think is necessary make something to simplify the task for translators.
Maybe some bat files for ResourceHacker (or something more) to extract, and rebuild the files to translate can be nice.
I'm not sure when I might get around to automating the MUI file creation/merging.
However, if you already have Resource Hacker and you prefer to avoid MUI files entirely then there isn't anything else I can automate with Resource Hacker in the first place!
All you have to do is to open the program in Resource Hacker, click the String Table resource, and click Action->Change Language For This Resources. Then just make your translations and click save, and now you have a working translated executable.
Note that the nice thing about MUI files is that they can be updated independently from the program, so that the next time you update the program, you can keep using it with the previous MUI file without having to modify anything. This is something you will want regardless of the particular file format (text or MUI or otherwise), so you will have to keep both files around regardless. (Deleting the MUI and relying solely on the EXE is a bad idea, because it's easy to overwrite it when updating, and because it means you now have to do a lot more extra work when updating, so it wouldn't save you any work.) This means you'd only need to create the MUI file once (or very occasionally), not every time you update. The only thing left that could be automated here is the merging of the MUI file back into the executable (in case you intend to distribute it later?) but it is already pretty easy with Resource Hacker...
Last edit: - 2018-04-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow, thank you! It's awesome to see all of you translating the software.
If you'd like to just continue leaving the links here, that's perfectly fine -- just note that your links may die quickly. (e.g. I think the link of the person who posted the Spanish file is dead.)
However, if you'd like me to redistribute them, unfortunately I don't think I can legally do that without an explicit license granting me that permission. If that's something you'd like me to do, you should probably let me know explicitly, because I don't have a procedure for that in place yet, and so I would need to figure out something.
(However, if you're fine with a completely free license such as CC0 or Public Domain, I wouldn't need anything further from you besides an acknowledgment that that is your license.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2018-05-24
SwiftSearch v6 & v7, Russian localization.
I give to your full disposal without any obligation.
There are only 2 questions:
1. Why did the program become 2 times "heavier"?
2. Is there an option to make the version of the program for WinPE
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This surprised me too! The reason turned out to be that I am now using a second copy of the Boost.Xpressive regular-expression (regex) engine specialized for char (for ASCII text), in addition to the original one for wchar_t (for Unicode). This allowed me to lower the program's memory usage a fair bit for English users (ASCII uses only 1 byte per character, UTF-16 uses at least 2) and also improve searching speed. But it's a huge library, hence the file size increase. (Though I think you should be able to UPX it to compress it if needed.)
The program should already work in Windows PE. I just tried it on Windows PE 8.1 x64 to make sure, and it worked fine. Is it not working for you? If so, let me know what version of Windows PE and what error you are observing.
And thank you so much, that's really nice of you! When I get the chance I'll probably either upload the files separately or incorporate them into the program. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2018-06-07
I've tested this now making the "ru-RU" folder, works, but this not loading the strings from Menu.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, unfortunately the menu text seems to be embedded in the menu resources rather than in the string tables. I was hoping to find a good way to address this in the near future but I haven't yet... hopefully soon!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This include 3 bat and 2 script files to use along ResourceHacker (Use with ResourceHacker 5.0.42 or newer!)
Put in the same folder the executable files ResourceHacker.exe and SwiftSearch.exe.
Now we have something like this:
Making the translation. This is really simple too :)
1. Use '01 extract.bat'
This will generate a 'SwiftSearch.rc' file wich have all strings necessary to translate.
Open in an text editor and translate everything inside "quotes".
I recommend AkelPad, Notepad++ or something so, because they have syntax highligh for RC files, making this easier to read.
2. One time translated all strings from SwiftSearch.rc file, use '02 compile.bat'
This will make a 'SwiftSearch.res' binary file.
We can view and modify this file with ResourceHacker, if want.
3. Now use '03 addoverwrite.'
Making finally our SwiftSearch executable (SwiftSearchNew.exe) translated and ready to use :)
Additional notes
If want make use the translation without make a SwiftSearch.exe with the translation applied, we can open the SwiftSearch.res (generated in the step 2) with ResourceHacker and saving as .dll.
Rename this .dll file as 'SwiftSearch.exe.mui' and put this in a folder named with the current system locale name along SwiftSearch.exe.
We can get the current system locale name with SwiftSearch using the option 'Help > Translation'
And this is all.
I think can be nice leave this in "Translations (by the community)" section. What think the admin?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2018-06-08
I have errors in the last version of ResourceHacker when compiling. In version 3.4.0.79 there are no such errors. I think the new version incorrectly handles back slashes
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not everything is so simple...
" 3. Now use '03 addoverwrite.'
Making finally our SwiftSearch executable (SwiftSearchNew.exe) translated and ready to use :)" This way everything turns out well.
If want make use the translation without make a SwiftSearch.exe with the translation applied, we can open the SwiftSearch.res (generated in the step 2) with ResourceHacker and saving as .dll.
Rename this .dll file as 'SwiftSearch.exe.mui' and put this in a folder named with the current system locale name along SwiftSearch.exe. But in this way - the menu for some reason remains not localized:
Support to translate the program in different languages.
Done.
Strings are now in the executable's string table and can be translated into other languages.
Whoa, that was quick, thank very much :D
How I can make the language file? I don't know how make i honestly
By now I've translated the text in SwiftSearch with ResourceHacker heh.
Here SwiftSearch 6.3 translated in Spanish
https://www.hidrive.strato.com/lnk/GOAiHt1m
Resources modified:
dialog 101 1033
dialog 102 1033
menu 105 1033
string Table 7 1033
string Table 8 1033
string Table 9 1033
string Table 10 1033
Why don't make translations with something simpler like .ini or gettext (.po) files?
Thanks!
An MUI file is just a PE file (DLLs and EXEs are PE files) that contains resources... at least as far as my program is concerned. (Everything else in the file is ignored.) It's the standard method for localization in Windows; it doesn't really make sense for me to create my own (inevitably buggy) file format and parser from scratch just for this.
The MUI file needs to be in a subfolder with the same name prefix as the program followed by
.mui, so something likeen-US\SwiftSearch.exe.mui.To create an MUI file, "unofficially" you could just use a program like Resource Hacker to save the executable's
String Tableto a.resfile (to remove the embedded code etc.), open that.resfile again and save it as a.dllfile, then rename that.dllfile to a.exe.muifile, likeSwiftSearch.exe.mui. Then just put that in the right subfolder (e.g.en-US).Now you can open it again in Resource Hacker and modify it to your heart's content. Just make sure to change the language ID as appropriate (it should already be 1033 for English).
If it's in the right folder, my program will try to use it before falling back to the English text. You can make sure that it's working by deleting the String Table in the executable so that the strings will be empty if the MUI file isn't present.
(Let me know if this doesn't work -- I haven't tested it since it's a bit difficult to test on an English system.)
If you wanted to create the MUI file "officially", you could do something like this:
en-US.MUIConfig.xmland copy-paste this inside it:<?xml version="1.0" encoding="utf-8"?><localization><resources><win32Resources fileType="Application"><localizedResources><resourceType typeNameId="#6" /></localizedResources></win32Resources></resources></localization>muirct -q "MUIConfig.xml" -x en-US SwiftSearch.exe SwiftSearch.ln.exe en-US\SwiftSearch.exe.muiNote that MUIRCT is located in the Windows SDK folder, such as
%ProgramFiles(x86)%\Windows Kits\8.1\bin\x64\muirct.exe.ln(language-neutral) executable; it's basically the original executable with the resources removed (and some minor stuff added).Does this make sense?
Also, oops, I just realized the dialog resources also have embedded text that I don't load dynamically; thanks for mentiong that! I just fixed this in my code, so you should see this the next time I release a new version. (It's not worth making a new release just for this.)
Last edit: - 2018-04-24
By the way, I think it might also be possible to avoid MUI files by just adding a string table to the executable with the correct language ID (without needing to modify the existing one). Microsoft seems to suggest this should "just work". The benefit is that you only have that one executable, so it's nice if you don't want to give people multiple files. The downside is you'll have to copy around the resources every time there's a new version.
Okay, I'll do it in the "unofficial" although approved way hehe.
I've tested this now making the "es-VE" folder, works, although yes, is not loading the strings from Dialog and Menu.
I'm not sure about how this will works with the other spanish "variants" like es-AR, es-MX, es-ES, etc. I guess this have some simple solution but I don't know until now.
Also I guess the same apply for other languagues with your own variants.
I'm agree with you in use the standard method for localization in Windows is the best way, but I think is necessary make something to simplify the task for translators.
Maybe some bat files for ResourceHacker (or something more) to extract, and rebuild the files to translate can be nice.
Avoiding MUI files and have the translation with the executable is better without doubt :)
This is my locale file for now :)
https://www.hidrive.strato.com/lnk/dAginpum
I'm not sure when I might get around to automating the MUI file creation/merging.
However, if you already have Resource Hacker and you prefer to avoid MUI files entirely then there isn't anything else I can automate with Resource Hacker in the first place!
All you have to do is to open the program in Resource Hacker, click the String Table resource, and click Action->Change Language For This Resources. Then just make your translations and click save, and now you have a working translated executable.
Note that the nice thing about MUI files is that they can be updated independently from the program, so that the next time you update the program, you can keep using it with the previous MUI file without having to modify anything. This is something you will want regardless of the particular file format (text or MUI or otherwise), so you will have to keep both files around regardless. (Deleting the MUI and relying solely on the EXE is a bad idea, because it's easy to overwrite it when updating, and because it means you now have to do a lot more extra work when updating, so it wouldn't save you any work.) This means you'd only need to create the MUI file once (or very occasionally), not every time you update. The only thing left that could be automated here is the merging of the MUI file back into the executable (in case you intend to distribute it later?) but it is already pretty easy with Resource Hacker...
Last edit: - 2018-04-24
The localized file in Russian
Wow, thank you! It's awesome to see all of you translating the software.
If you'd like to just continue leaving the links here, that's perfectly fine -- just note that your links may die quickly. (e.g. I think the link of the person who posted the Spanish file is dead.)
However, if you'd like me to redistribute them, unfortunately I don't think I can legally do that without an explicit license granting me that permission. If that's something you'd like me to do, you should probably let me know explicitly, because I don't have a procedure for that in place yet, and so I would need to figure out something.
(However, if you're fine with a completely free license such as CC0 or Public Domain, I wouldn't need anything further from you besides an acknowledgment that that is your license.)
SwiftSearch v6 & v7, Russian localization.
I give to your full disposal without any obligation.
There are only 2 questions:
1. Why did the program become 2 times "heavier"?
2. Is there an option to make the version of the program for WinPE
Great questions:
This surprised me too! The reason turned out to be that I am now using a second copy of the Boost.Xpressive regular-expression (regex) engine specialized for char (for ASCII text), in addition to the original one for wchar_t (for Unicode). This allowed me to lower the program's memory usage a fair bit for English users (ASCII uses only 1 byte per character, UTF-16 uses at least 2) and also improve searching speed. But it's a huge library, hence the file size increase. (Though I think you should be able to UPX it to compress it if needed.)
The program should already work in Windows PE. I just tried it on Windows PE 8.1 x64 to make sure, and it worked fine. Is it not working for you? If so, let me know what version of Windows PE and what error you are observing.
And thank you so much, that's really nice of you! When I get the chance I'll probably either upload the files separately or incorporate them into the program. :)
I've tested this now making the "ru-RU" folder, works, but this not loading the strings from Menu.
Yeah, unfortunately the menu text seems to be embedded in the menu resources rather than in the string tables. I was hoping to find a good way to address this in the near future but I haven't yet... hopefully soon!
Finally I did what I wanted to do to make the translation of SwiftSearch easier :D
Preparing the necessary to make the translation. This is really simple.
Download and extract the following zip file in any folder, by example: "SwiftSearch Languague".
https://mega.nz/#!IvhnkYYA!LO2rumcZT9rdg5iyicCn3-XoegVXi6P5u32KkIKSmFc
This include 3 bat and 2 script files to use along ResourceHacker (Use with ResourceHacker 5.0.42 or newer!)
Put in the same folder the executable files ResourceHacker.exe and SwiftSearch.exe.
Now we have something like this:
Making the translation. This is really simple too :)
1. Use '01 extract.bat'
This will generate a 'SwiftSearch.rc' file wich have all strings necessary to translate.
Open in an text editor and translate everything inside "quotes".
I recommend AkelPad, Notepad++ or something so, because they have syntax highligh for RC files, making this easier to read.
2. One time translated all strings from SwiftSearch.rc file, use '02 compile.bat'
This will make a 'SwiftSearch.res' binary file.
We can view and modify this file with ResourceHacker, if want.
3. Now use '03 addoverwrite.'
Making finally our SwiftSearch executable (SwiftSearchNew.exe) translated and ready to use :)
Additional notes
If want make use the translation without make a SwiftSearch.exe with the translation applied, we can open the SwiftSearch.res (generated in the step 2) with ResourceHacker and saving as .dll.
Rename this .dll file as 'SwiftSearch.exe.mui' and put this in a folder named with the current system locale name along SwiftSearch.exe.
We can get the current system locale name with SwiftSearch using the option 'Help > Translation'
And this is all.
I think can be nice leave this in "Translations (by the community)" section. What think the admin?
Wow, awesome, thank you! I uploaded it there and linked back to here.
Woops, I've included a "ResourceHacker.ini" by error in the zip. This is not necessary, this is generated by resourcehacker automatically.
Here my Spanish translation for SwiftSearch 7.1.3
Updated both, thanks!
I have errors in the last version of ResourceHacker when compiling. In version 3.4.0.79 there are no such errors. I think the new version incorrectly handles back slashes
Interesting, thanks for the heads-up! I haven't encountered troubles in 4.2.5 either, but I haven't tested it much.
Not everything is so simple...
" 3. Now use '03 addoverwrite.'
Last edit: ALEKSANDR MAKEEV 2018-06-28
I also have this situation.
Here are the .rc and .res files russian lang compiled by ResourceHacker 5.0.42
Last edit: ALEKSANDR MAKEEV 2018-06-29
Hi, everyone,
By clicking on this link, you can download the French translations of SwiftSearch 7.4.2 32 and 64 bits in French
https://www.colok-traductions.com/modules.php?name=Blogs&op=billet&bid=2582#billet
Best regards
Colok
Thank you! I extracted and uploaded the translation file. :)