Hello, when I select Check for Updates, begin to download the application and start to install, the application asks the installation language as default I have Spanish (Latin America).
Is there any way to put this language default and automatically select or not ask? Since updating left and stops applications for this reason.
Greetings.
You are here
[Fixed] PortableApp Updater installation language question
January 22, 2013 - 11:15am
#1
[Fixed] PortableApp Updater installation language question
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
The installers installed via the updater should automatically run silently unless they need to show a license. The only time I've seen this not work is if you've renamed your PortableApps directory to something else for some reason. This will short-circuit the app installer's ability to run silent.
Sometimes, the impossible can become possible, if you're awesome!
Hi John, Thanks for responding.
My installation is PortableApps default directory, I have not changed, and I have checked the settings selected SpanishInternational language / Español (Alfabetización Internacional), but had marked the check "Use this language for the portable apps", I'll try then if this option works without asking installation language for almost all Apps that are being updated.
Greetings.
I agree with renetrevi! I told installer to install several applications and I had to select my language many times. Although I have set that I use Slovak language in settings.
I think that there should be another parameters in settings for language:
1. Closest language to my native language. For instance: I am Slovak and if application is not available in Slovak, there is a pretty good chance that exist in Czech language. Slovak and Czech languages are very similar.
2. And there should be another parameter like:
Use English or default language (I mean language which is default for application).
So if application is available in Slovak, installer should choose Slovak. If Slovak is not available, it should check, if Czech language is available. And finally, if there is not Slovak nor Czceh language, it should automatically choose English if parameter "Use English or default language." is checked.
Thanks a lot
Please list the operating system, full install path and any other pertinent details. Also list any other software or utilities that are running. Something is interfering with standard Windows processes like mutexes, environment variables and the like. The only thing I've heard of doing this so far is Pokki Menu which was reported by another user to interfere with mutexes and/or environment variables.
Sometimes, the impossible can become possible, if you're awesome!
Hello,
I have the same issue, but with English.
I have set my PortableApps.com Platform language to
EnglishGB, and while many Apps will install without prompting, any App which specifies which languages are allowed (and does not explicitly includeEnglishGB) will prompt me to select a language, even if it does includeEnglish(w/o "GB").As most if not all English speakers will be able to understand either variant of English (the spelling will just look wrong to them), this could be solved by making English
& EnglishGBbe able to fall back on each other if the preferred variant of English is not included in the installer, or possibly by making theENGLISH=trueline automatically include both variants.Either of the above possibilities could also be used by other languages, as long as both variants will be intelligible to readers of the other.
e.g. I do not know if
TradChinese& SimpChinese are eligible for such a fall-back/transclusion system or not, will someone who knows one be able to read the other or not? What aboutSpanish&SpanishInternational~3D1T0R
I've confirmed this. It's a bug in the PortableApps.com Installer where it does not automatically fallback to English if the exact language passed from the platform isn't present. It affects 66 apps in total. It will trigger anytime the app being installed is set to multilingual with languages available in the installer.ini but not your current language.
I'm working out how best to address it for all affected languages as quickly as possible. My apologies in not having this sorted earlier due to it looking like another issue was triggering it.
UPDATE: This also affects apps with Multilingual installers that do not specify which languages are available in installer.ini if the language set in the platform was not yet available in the PA.c Installer when the installer was compiled. For example, if you have the platform set to EnglishGB but install an app from before we had EnglishGB set in the installer, the language selection will pop up.
Sometimes, the impossible can become possible, if you're awesome!
As an EnglishGB (we don't actually use that term that way, BTW) person I've just checked and my PA is set as English, i.e. implied EnglishUSA (which you really should be using rather than plain English to be similarly idiosyncratic
People differ about this, e.g. if I'm processing words I want the spelling correct, however, if I am using an accounting app I don't care if the red for negative is color or colour in the settings so long as the double entry is right.
For folk like EDITOR, myself and JTH these are an irritation rather than a show stopper. For people in increasingly remote (from english) languages I suggest this can be a major problem.
I've done some googling for "language fallback tables" and similar but I've concluded I'm not in a good position to judge which are good v bad outside the language families I am familiar with. A lot of them seem to jump straight to english whereas our correspondents above clearly indicate there is a path of sorts more natural to them.
Spanish (Local) -> Spanish (Generic)
Slovak -> Czech
most transitions will probably end up in english of some sort for our purposes as that is the common language of this site if nothing else is available but should we jump straight there?
For someone wanting to have their app here for publicity and marketing and indeed international exposure beyond their language base the effort should be on their side I feel.
For someone wanting to get an app from here maybe we can help a little more by finding a language path from native to english?
It may end up as english for many apps but would it really be hard to find a good table and use it or define one based on user experience?
No rush to reply, folks, thoughts for the long term.
Wm
This is a side issue to the bug being discussed here. The bug is prompting users to select a language at all when the installer should be running entirely in silent mode, meaning it won't even be visible so the language won't even matter except for an app like LibreOffice (where we set the language for the user on install) or an app where there is a license agreement. It's entirely a technical bug as it's supposed to fall back to English automatically already, so that's all that we need to discuss at the moment. I'll likely include some basic fallbacks at some point later, but that's not the primary concern at the moment.
Sometimes, the impossible can become possible, if you're awesome!
EnglishandEnglishGBare the filenames used in the Platform's Locale directory (both having the extension of.locale), thus they are what shows up on the left side of the/in the Options window and what I figured would get the point across to John T. Haller most effectively. That's why I chose to to indicate which I meant in that way.As far as Silent Installers go, it doesn't matter so much what language the installer windows use as they're all hidden, as long as the the app being installed gets the correct language installed and set (if available).
Also to mitigate this (and also to get a better flow when installing/updating) when a EULA is to be displayed, perhaps
PortableAppsUpdater.exeshould display all the applicable EULAs prior to downloading the installers. This would also help to lower install/update time in the case where the end user decides not to accept one or more of the EULAs presented.And on another note, probably the most annoying bug I've found (English-GB/US-wise) is that every time I update to a new version of the Platform I have to go back to the options (window or
inifile) and switch back to British English.For some reason the installer is convinced that I should use American English.
~3D1T0R
As I've already indicated this is a side issue. Let's stop discussion on this here.
Of all 300+ apps we have, only one app sets the language of the app within the installer and that's LibreOffice/OpenOffice. And it'll set it back when you run it with the platform anyway since the launcher also handles the switching.
The updater showing all EULAs in the beginning is a feature request that is already planned but will not happen until I have time to work on it. Another separate issue for a different thread.
Your updating switching you from EnglishGB to English is yet another separate issue. I wish you'd reported it earlier as it took me exactly 45 seconds to fix in the platform's installer so it'll be fixed in the next release.
Sometimes, the impossible can become possible, if you're awesome!
OK, just this one last post.
Thanks.
Sorry I didn't mention it earlier.
~3D1T0R
Ok, this is going to take a multi-pronged plan of attack since it's a bug in the PA.c Installer. So here's my plan.
Installer Fix and Improvement
I'm finishing up a fix for the PA.c Installer to detect when the included languages don't include the one you have set in the platform. Currently, this pops up the language selection prompt. It was supposed to just fall back to English.
I'm adding in code to do a more graceful fallback. These fallbacks will be included. When the language you have selected in the platform is not included in the set of languages in the PA.c installer, if the platform's language is:
- EnglishGB, fall back to English
- SpanishInternational, fall back to Spanish. If no Spanish, fall back to English
- Spanish, fall back to SpanishInternational. If no SpanishInternational, fall back to English
- PortugueseBR, fall back to Portuguese. If no Portuguese, fall back to English
- Portuguese, fall back to PortugueseBR. If no PortugueseBR, fall back to English
- All others, fall back to English
This should allow us as graceful a fallback as possible.
Platform Updater/App Store Workaround
The above will be fine for new and updated apps and will allow them to work properly no matter what the language the platform is set to, so we don't need to worry about those. Nor do we need to worry about apps in one language only. We do need to worry about the rest, though. So, I'll be detecting if an installer is multilingual (either specifying languages or not) and whether it is less than version 3.0.10, meaning it has this bug and must be handled specially.
When the updater/app store detects an app of this nature, I'll have it set it in English only as a base fallback for now. It won't matter much as most apps will run completely silently. It will matter for apps with optional components that aren't handled automatically (not sure if any fit that bill anymore) and for apps that need to show an EULA. The EULAs are still all in English, so it doesn't matter as much, it'll be the UI "Agree to this..." "OK/Cancel" showing up in English instead of native. I may push up the feature to combine EULAs into a single one at the beginning over one of the other features I'm working on for the next beta, but we'll see over the next few days.
I considered determining what languages are supported in the installer, but that would involve extracting out the installer.ini which will be slow due to installers using SOLID /lzma compression... meaning it has to extract the whole installer to get at that one file.
I think that about does it for now. I've just about completed the installer fix and will be posting it today. I'm holding off on updating the currently outdated apps until then.
Sometimes, the impossible can become possible, if you're awesome!
I agree that extracting the installer.ini to detect supported languages would be too slow to make sense.
Would it be worth hosting a copy of the installer.ini file for released apps somewhere separate from the installer so the Updater/Directory can download it instead of extracting it? or would it be better for someone to go through and make a list which the Updater/Directory can reference? (I can do that if it'll help you)
If I understand correctly, Apps released after the new version of PA.cI won't need the workaround, so I assume such a list would be made once of all the affected apps (including version #) and as they get updated (thus the version number changes) they effectively fall off of the list, correct?
If you want me to make that list just tell me.
I was thinking along these lines:
Check if
LangWorkaround.ini:[AppNamePortable]:PackageVersionis the same asUpdater.ini:[AppNamePortable]:PackageVersionand if it is check forLangWorkaround.ini:[AppNamePortable]:LANGUAGENAME=trueetc. (or something similar to that)
LangWorkaround.ini
~3D1T0R
Unfortunately, that's not quite enough because some apps were packaged before EnglishGB or Vietnamese were added, for example. So, they have Multlingual set on in appinfo.ini but no installer.ini present (aka all languages supported by the installer). Those apps will need additional things set on or off, which will complicate things a tad. I was thinking along the same line you were of having indications in the updaterDB about which apps support which languages properly. I'll think it through a bit more today. It won't delay releasing the installer update or apps to wait and determine the best solution.
Sometimes, the impossible can become possible, if you're awesome!
I was thinking of having a separate
.inifile as a database of (most-recent-version) affected apps, but including it directly into Updater.ini would certainly work too, the format would just have change accordingly.That example was just to display what format I was considering for the
LangWorkaround.iniI was suggesting, which I was thinking would only include apps that were directly affected by the bug.I would be willing to check the older apps myself to see if they're affected by the 'Silent-Installer asks for language' bug, and add only the languages that don't trigger the bug (unless you'd prefer it be done differently).
~3D1T0R
If you want a south American rodent (leave the armadillo alone soccer fiends!) to test things on I'm happy to play guinea pig as folk like ED and myself are one shift away but well within the language family so unlikely to lose anything if we try something really foreign (presuming some value of distance from english in grammar, character set, etc).
I'll happily follow this in another sub-forum if you feel it is better placed elsewhere.
Wm
I've been looking through the apps and considering this a bit more. Now that the installer is fixed, the first thing we can do in the updater/app store is to check the PA.c Installer version and, if it's 3.0.10 or later, just proceed with the install as we do now.
For 3.0.9 and earlier, we'll need to do some workarounds. And that will vary a bit by how the app is setup. We have a couple different kinds of apps affected:
1. Apps set to Multilingual in the appinfo.ini but no languages specified in the installer.ini (around 165 apps)
2. Apps set to Multilingual in the appinfo.ini and with languages specified in the installer.ini (around 55 apps)
Apps of the 1st type are using every language used in the installer for the specific version we have available. This is mostly only an issue for languages present in the platform but not the installer. Or apps with older installers that predate the addition of EnglishGB, Vietnamese, etc (only a couple apps may be affected).
Apps of the 2nd type are using specific languages and we can't tell which languages from outside the installer. The PA.c Installer exposes the version it is and a few other bits of information, but it does not expose the languages it has compiled in. I'd mentioned earlier that we could extract out the installer.ini using 7-Zip (the command line version is bundled with the platform), but this would require extracting the whole archive to temp since it's compressed with LZMA solid.
Now, trying to specially handle all these apps would be... prohibitive, timewise... but there's another way. Of those 220ish apps, most of them will show no UI at all when run in automatic mode with the platform's updater/app store, in which case the selected language won't matter. The only time an app will show any UI is if the app is showing the EULA or if it is showing the installer options screen. We have 59 apps that show the EULA total. The options screen is now handled automatically by all apps since it has to do with whether to install additional languages, so it isn't shown.
Some of those 59 EULA apps, we don't need to worry about, since they're single language (Autoruns, DebugView, etc). So, we only need to worry about those apps that show an EULA and that fit criteria #1 or #2 above. And then I need to handle them accordingly. So, I'll handle them like so:
1. For any apps that show an EULA that fit criteria #1 above, I can compare the platform's language to a pre-determined set of languages compiled into the app store/updater. If the current language of the platform is in that set, run as normal. If it is not, run as English.
2. For any apps that show an EULA that fit criteria #2 above, I can include a set of languages that app supports within the Updater Database just as a single line (Languages=English,French,etc). If the current language of the platform is in that set, run as normal. If it is not, run as English.
This should allow us to handle all apps for all languages without needing to go through and update a couple hundred apps. I'm happy to hear any feedback to this approach as I probably won't have time to begin implementing it for a day or two.
Sometimes, the impossible can become possible, if you're awesome!
This approach sounds like it should be the least painful way of handling this issue.
If you already have a list of the 59 apps, I'm willing to compile the language list for you in that format if you'd like.
If not, I'm willing to pore through the app list to find them.
The updater.ini includes EULAVersion= for each app that uses an EULA. It's part of the system I'm adding allowing the updater/app store to display all EULAs up front. The version is needed to compare to the last agreed to version in the installed app's license.ini so we can show an EULA to the user when it's been updated.
Sometimes, the impossible can become possible, if you're awesome!
That'll make it quicker to compile a list. I'll get that done tomorrow morning.
Pro Tip: Apps that have already been updated to 3.0.10 and don't need to be cataloged have a comment at the end of their listing that ends in an m. So ;um or similar.
Sometimes, the impossible can become possible, if you're awesome!
I finished this earlier this afternoon, but had to rush out the door before sending it in. Will have it sent tomorrow when I'm back on the computer.
I've sent this list to John via email for his perusal. If anyone else wants a peek, it's on pastebin. Note that the final look may change, based on developer preference.
http://pastebin.com/MVNbSRXt
With today's release of PortableApps.com Installer 3.0.10, the installer will fallback to alternate languages where available (SpanishInternational to Spanish and vice versa, PortugueseBR to Portuguese and vice versa) and fallback to English when the language of choice via the platform and the fallback if any is unavailable when run via the platform's app store, updater, or install a new app functions. This fixes the issue properly for releases going forward. I'll be finishing up the workaround for the platform shortly for existing apps in older installer packages.
Sometimes, the impossible can become possible, if you're awesome!
John and friends, it is stuff like this that makes me happy to recommend PA.
Wm
Wanted to say that I tested PA.cI v3.0.10 and the fix appears to work perfectly for me.
Thank you JTH.
~3D1T0R
This is fixed in 12.0 Beta 4 which was posted today. Please test to ensure that it works properly for you.
The PA.c Installer was fixed with version 3.0.10, as posted above. The PA.c Updater in the platform has an added workaround to switch app to English for the installer if the installer predates PA.c Installer 3.0.10. As it will be running in silent mode, it won't affect most apps. The only apps affected are those with EULAs since the UI will show for that one screen, so we're going to prioritize updating those.
I'm leaving this bug open until Tuesday when we post 12.0 Final.
Sometimes, the impossible can become possible, if you're awesome!
This was already fixed in the beta but is now fixed in 12.0 stable as well.
Sometimes, the impossible can become possible, if you're awesome!