You are here

Home » Forums » Support Forums » Other Apps Support (Deprecated)

[Closed] Language problems in IObit Unlocker Portable 1.0

9 posts / 0 new
Log in or register to post comments
Last post
January 11, 2013 - 12:12am
#1
tapsklaps
Offline
Last seen: 4 years 5 months ago
Developer
Joined: 2010-10-17 08:11
[Closed] Language problems in IObit Unlocker Portable 1.0

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:

  1. 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%
  2. 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

Top
January 11, 2013 - 12:29am
John T. Haller
John T. Haller's picture
Offline
Last seen: 3 hours 3 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Clarification

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!

Top
January 11, 2013 - 12:46am
(Reply to #2)
tapsklaps
Offline
Last seen: 4 years 5 months ago
Developer
Joined: 2010-10-17 08:11
matter of opinion

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.

Top
January 14, 2013 - 4:10pm
John T. Haller
John T. Haller's picture
Offline
Last seen: 3 hours 3 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Admin

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:

[Language]
Base=%PortableApps.comLocaleName%
CheckIfExists=%PAL:AppDir%\IObitUnlocker\Language\%PAL:LanguageCustom%.lng
DefaultIfNotExists=English

[LanguageStrings]
EnglishGB=english
SimpChinese=ChineseSimp
TradChinese=ChineseTrad

[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%

Sometimes, the impossible can become possible, if you're awesome!

Top
January 14, 2013 - 8:09pm
(Reply to #4)
tapsklaps
Offline
Last seen: 4 years 5 months ago
Developer
Joined: 2010-10-17 08:11
no real difference

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".

Top
January 14, 2013 - 8:16pm
(Reply to #5)
John T. Haller
John T. Haller's picture
Offline
Last seen: 3 hours 3 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
App Fails

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!

Top
January 14, 2013 - 8:45pm
(Reply to #6)
tapsklaps
Offline
Last seen: 4 years 5 months ago
Developer
Joined: 2010-10-17 08:11
convincing argument

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])

Top
January 14, 2013 - 8:53pm
(Reply to #7)
John T. Haller
John T. Haller's picture
Offline
Last seen: 3 hours 3 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Right

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!

Top
January 14, 2013 - 9:18pm
(Reply to #8)
tapsklaps
Offline
Last seen: 4 years 5 months ago
Developer
Joined: 2010-10-17 08:11
conclusive explanation

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?

Top
Log in or register to post comments