I've read through several times the complete documentation of Languages. Based on the explanations in the "Setting a custom language environment variable" I've come to the conclusion, that the environment variable %PAL:LanguageCustom% exclusively will be applied in the PortableApps.com Platform. This environment variable is generated by the sections [Language] and [LanguageStrings].
On the other hand the section [LanguageFile] will only applied, if the portable program is started outside of PortableApps.com Platform. From this I deduced, that the section [LanguageFile] not uses the environment variable %PAL:LanguageCustom%. Instead the section [LanguageFile] uses a particular file.
Are these statements so far correct?
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
The whole point of language switching is for use with the platform (what other reason is there? We certainly don't want it always changing to match the host OS.) Keep in mind that users can disable automatic language switching within the Platform as well, so it may use the fallback with the Platform in that case. LanguageCustom is set appropriately based on both the platform environment variables and then what is read in from the language file setting in the app if the environment variables don't exist.
Sometimes, the impossible can become possible, if you're awesome!
To reach that goal, the user must click on "Options" in the PortableApps.com Menu.
In the dialog window named "Options" the user chooses the tab "General". In the section "Language" he now disables the checkbox next to "Use this language for all portable apps". Is this procedure so far correct?
You have mentioned in your last sentence the possibility, that an environment variable don't exist. Does that mean, that some languages exists, which are not integrated in the PortableApps.com Platform?
Is my assumption so far correct, that the section [LanguageFile] only uses a particular file. If such a file does not exist, then the section [LanguageFile] is not applied. In no case this section uses the environment variable %PAL:LanguageCustom%.
These environment variables only exist when launched from the Platform.
PAL:LanguageCustom always point to the correct language; it gets it from [Language] and [LanguageStrings] when launched from the Platform, and from [LanguageFile] otherwise.
Tip: Use the Source, Luke
Previously known as kAlug.
your information are as always a little bit unclear
Sorry about that. It's not exactly easy to answer from my cell phone.
So let's answer your questions:
1. Yes (at least my memory says so).
2. The environment variables John mentioned are provided by the Platform, what means that they are only present when launched by it.
3.
PAL:LanguageCustomcontains the final value of the language. It's not used anywhere; it's set by PAL's Language segment and then you just do what do you need do to with it (write to/copy a file, set an environment variable, etc.).The
[LanguageFile]section is used to read the language from a file so the launcher knows the proper language to set when not launched from the Platform. You'll need to write the value ofPAL:LanguageCustomto the same file too.I don't think I can more clearer than all my answers together. If you have doubts and no one here manages to answer them, read the source.
Previously known as kAlug.
I'm with you totally agree, that the section [LanguageFile] is used to read the language from a file. But when the program is not launched from the PortableApps.com Platform, then I think, that the launcher not interpreted the two sections [Language] and [LanguageStrings] (because these two sections are evaluated only when the program is started within the PortableApps.com Platform). Since, however, the environment variable %PAL:LanguageCustom% only is created in the sections [Language] and [LanguageStrings], this variable does not exist when the program is started outside of PortableApps.com Platform. Thus the section [LanguageFile] can't use this non-existent environment variable %PAL:LanguageCustom%.
follow kAlug's advice to read the source, it is well documented and should answer all your question (or scrap your suppositions...)
I know, you don't trust until you find out by yourself, but sometimes you should try.
Hi tapsklaps!
)
I see, this still bothers you. Have you noticed my advice to run a launcher in debug mode? I could build my experimental version of tomahawk for you as debug version so you could test it under different conditions. (Tomahawk because I think you have investigated this app's stuctures thoroughly the last days.
In debug mode, you see every action the launcher takes step by step and you have a debug.log in Data you could study afterwards.
To your questions:
%PAL:LanguageCustom% is not "used" but set by the launcher depending various conditions that you have to define in the launcher.ini and LanguageFile is the part to get the desired value from a file in case the platform variables are not present - either cause of launching standalone or by disabling automatic language setting... You have to define what the launcher should do with that variable, according to way the app should work.
Remember: 3 is only applicable if run standalone.
-edit-
Oh, I think, I forgot to scroll down. I see kAlug already answered your questions exhaustively.
I'm agree with you regarding your answers No. 1 and 2.
Regarding your answer No. 3 following:
Please explain me exactly, what you want to say with your very unclear statement:
As I have already tried several times to explain this variable is generated exclusively by the two sections [Language] and [LanguageStrings]. If the program is not launched in the PortableApps.com Platform, then this variable not exists. Then the section [LanguageFile] can't use this non-existent variable.
You are wrong.
As I tried to explain several times, the variable is generated by the launcher from Language and LanguageStrings in case it is launched from the platform and read from LanguageFile if not. It is as simple as that.
Only in case the section LanguageFile is not present when the launcher is launched standalone it reads the Language section as fallback and would set the language to english according to the format specified in Base.
From now on I will put my assistance on hold until you either have read the source or tried a launcher in debug mode. Your theoretical assumptions seem not to help you to understand how the launcher works. You just guess from what you think is right according to your findings by simply reading parts of the manual and analysing some outcome from some launcher setup.
It is all layed out, we pointed you to the different information sources, but I get the feeling that you don't use them thoroughly enough. For instance: This whole thread is kind of redundant. May I remind you that I pointed you to the launcher manual for this exact issue?
No offence meant, but I'm getting weary.
In the first half of your sentence you mentioned, that the launcher generated the variable by the two sections [Language] and [LanguageStrings], when the program will launched in the PortableApps.com Platform. That's ok and I'm agree with you.
In the second half of your sentence you mentioned, that the section [LanguageFile] uses this variable, when the program will not launched in the PortableApps.com Platform. But please explain me, how this variable will be generated in this last case?
I would now like to end this dispute, because you can not persuade me with your arguments. Sorry
Source or debug mode!
No need to persuade you if you don't want to learn...
Unfortunately I have not exactly read the following sentence:
Probably you seem to have right. Sorry
But what value is then assigned to this variable? When the program is not launched from the PortableApps.com Platform, then only the system language of the host PC can assigned to this variable. Or what would you think?
The value is specified in [LanguageFile]. Now PLEASE do some practical learning instead of analyzing answers. When build in debug mode, all relevant actions of a launcher are displayed.
Like this: http://screenshooter.net/5313111/omcmira
and this: http://screenshooter.net/5313111/vowdcon
First, you need a
[FileWrite]section to write the value of%PAL:LanguageCustom%to some file. You also need a[LanguageFile]section with approximately the same parameters as that[FileWrite]section.Now, when the app is launched from the Platform, the launcher will detect its language environment variables and set
%PAL:LanguageCustom%based on them. Right after that it will execute the[FileWrite]section.So, we have the value of
%PAL:LanguageCustom%written somewhere, right?Then, the app is launched directly by the user (i.e. not through the Platform). The launcher will not detect the Platform's language environment variables, and will then try to read the language as specified in the
[LanguageFile]section.Do you agree that now
%PAL:LanguageCustom%has the same value as of when we wrote it with[FileWrite]?After that, the launcher will execute the
[FileWrite]section as when it has been launched from the Platform.Previously known as kAlug.
And in addition it can make a language selected manually in the app itself persistent when launched standalone which otherwise will be reset to english. I already explained that here and earlier in that thread - but not as plausible as you.
Your first 4 paragraphs are absolutely clear.
Before you can use the section [FileWrite], you need a value, which is assigned to the environment variable %PAL:LanguageCustom%. Afterwards you can read this value via the section [LanguageFile]. That's all logical so far.
But from where get the environment variable %PAL:LanguageCustom% a value, when the program will launched outside of the PortableApps.com Platform. This is my question? Because only after this variable has been assigned a value, can work the two sections [FileWrite] and [LanguageFile].
Please read my answer again, specially the third paragraph.
Now add this: if the app's first run is not through the Platform, the launcher will automatically fall back to English.
Previously known as kAlug.