In IObit Unlocker Portable 1.0 doesn't work the automatic switching of the language in the PA.com menu. To solve the problem of language, 2 changes are needed:
- Changes in the file IObitUnlockerPortable.ini
It's necessary, that the sections [Language], [LanguageStrings], [LanguageFile] and [FileWrite1] will be pasted in the file IObitUnlockerPortable.ini. Here now the content of these sections:
[Language] Base=%PortableApps.comLanguageCode% Default=en [LanguageStrings] ar-sa=arabic zh-cn=chinesesimp zh-tw=chinestrad cs=czech da=danish de=german en=english es=spanish fi=finnish hu=hungarian it=italian ja=japanese pl=polish ru=russian sv=swedish tr=turkish [LanguageFile] Type=INI File=%PAL:DataDir%\IObitUnlockerSettings\Main.ini Section=Main Key=Language [FileWrite1] Type=INI File=%PAL:DataDir%\IObitUnlockerSettings\Main.ini Section=Main Key=Language Value=%PAL:LanguageCustom%
- Changes in the Directory and File Layout
The creation of the folder DefaultData in the folder App is necessary. In the folder DefaultData will pasted the folder "IObitUnlockerSettings". Finally contains the folder "IObitUnlockerSettings" the file "Main.ini".
Here now the content of this file "Main.ini":[Main] FirstRun=0 Language=english
Here is the link for downloading the revised app: IObitUnlockerPortable_1.0_Rev_1.paf.exe
1,75 MB download/3,37 MB installed
MD5: 692be92633a119a9ec5579679f97ec53
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
Just a minor clarification. This is an enhancement, not a bug. Language switching is not currently required for released apps (though it may be in the future).
Sometimes, the impossible can become possible, if you're awesome!
Basically the portable apps should be designed in such a kind, so that the automatic switching of the language in PA.com menu works. From this perspective it would very well a bug and not an enhancement. But as one might also interpret it, in any case the above revised version is of better quality.
Forgot to mention that the above won't actually work, anyway, as when switching to admin with compile-force, the whole environment variable set is lost. At some point we may have a workaround. When we do, I'll add it like this:
Sometimes, the impossible can become possible, if you're awesome!
I compared your proposed solution with my and can absolutely see no qualitative difference between the two. These are two equivalent ways to solve the problem. Or can you explain me in more detail, why you've decided for your developed solution?
Also, I can not understand why you want to decide at all for the use of compile-force. Therefore please describe me a real case, where it's necessary, that you must use compile-force as admin and where my proposed solution doesn't work. In most cases it's sufficient, when you instead use "force".
With force, this app fails to work on Windows 7. Compile-force is required for it to work properly.
I included mine as it is cleaner. It supports more languages than yours. And it is future proof as it will automatically work with other languages as they add them. It's important to choose the variable that is closest to what the app uses. It makes for simpler launcher.ini files that are easier to maintain as additional languages are added. That's why we have multiple language environment variables instead of just picking one.
Sometimes, the impossible can become possible, if you're awesome!
Indeed you've right, that your solution is cleaner and more transparent. In fact it is necessary for my solution, in the case of a new language to add it in the section [LanguageStrings]. In your solution this works automatically without any alterations.
EDIT: But I must remark, that this is true only if the naming of new languages, which are added by the developer, is identical to the name under "LocaleName" (see the special cases, where you have added entries in the section [LanguageStrings])
Right, it's best to review, of course, but sometimes you miss one. The goal here isn't for it to always work, but for it to come close. In our example here, I believe you missed Dutch. With the latter setup, it wouldn't have mattered. This app follows LocaleName pretty closely. Usually, with apps that do, the only place they differ is in specific ones: SimpChinese, TradChinese, PortugueseBr and SpanishInternational. Most apps will closely follow one of the variables we have setup.
Sometimes, the impossible can become possible, if you're awesome!
Thanks again for this enlightening explanation.
Have you already looked in more detail on my proposed solution regarding the improvement of the language problem in the app PeaZip Portable? Is there anything, what you would alter in this code?