I noticed many different PortableApps.com language environment variables.
Exists an overview of them (name and how languages are stored)? Can't find one and want to select the best fitting one for my apps!
New: Kanri (Oct 09, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
Please donate today
Some apps depend on one type, others on another. For example, one of them produces ID numbers, e.g. 1034. Another produces language names, e.g. "French". Yet another will produce the two-character abbreviation, e.g. "de" (possibly with a locale, e.g. "en-AU"). It all depends on the app. Look at how it stores its languages and decide which one you need.
A note: originally-GNU-apps and gettext-based apps (ones which use .po and .mo files) generally use the abbreviations.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I know how my app store its language, but for a decision, a table with all possible PortableApps.com language environment variables would be helpful.
Well, Winmerge Portable uses "PortableApps.comLocaleID", Gimp Portable uses "PortableApps.comLocaleglibc", but what other variables could be used? And how do they store the language (ID number, string, two-character, four-character, two- and four-character, ...)?
Here's a sample result set from a 1.2 Test, which now sets the requisite environment variables:
Arabic:
PortableApps.comLanguageCode=ar-sa
PortableApps.comLocaleCode2=ar
PortableApps.comLocaleCode3=ara
PortableApps.comLocaleglibc=ar
PortableApps.comLocaleID=1025
PortableApps.comLocaleWinName=LANG_ARABIC
English:
PortableApps.comLanguageCode=en-us
PortableApps.comLocaleCode2=en
PortableApps.comLocaleCode3=eng
PortableApps.comLocaleglibc=en
PortableApps.comLocaleID=1033
PortableApps.comLocaleWinName=LANG_ENGLISH
German:
PortableApps.comLanguageCode=de
PortableApps.comLocaleCode2=de
PortableApps.comLocaleCode3=deu
PortableApps.comLocaleglibc=de
PortableApps.comLocaleID=1031
PortableApps.comLocaleWinName=LANG_GERMAN
Spanish:
PortableApps.comLanguageCode=es
PortableApps.comLocaleCode2=es
PortableApps.comLocaleCode3=spa
PortableApps.comLocaleglibc=es
PortableApps.comLocaleID=1034
PortableApps.comLocaleWinName=LANG_SPANISH
SpanishInternational:
PortableApps.comLanguageCode=es-mx
PortableApps.comLocaleCode2=es
PortableApps.comLocaleCode3=spa
PortableApps.comLocaleglibc=es
PortableApps.comLocaleID=3082
PortableApps.comLocaleWinName=LANG_SPANISHINTERNATIONAL
John T. Haller: it'd be good if we could get a table with all this in the development section.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
that's what I'm looking for!
A complete table in the development section would be good, cause I don't want to compare apples and oranges!
I want to know the differences between PortableApps.comLanguageCode, PortableApps.comLocaleCode2 and PortableApps.comLocaleglibc, especially for the languages with multiple locales (e.g.: en_US, en_GB, pt_BR, hi_IN,...).
Btw: Gimp Portable Launcher compares "PortableApps.comLocaleglibc" with "en_US", isn't that a bug when english is stored as "en"?
When the test release happens tomorrow, I'll post the list. I was gonna post it this weekend, but, well, I told you about my girlfriend getting mugged on Friday. So, it's only been posted to IRC developers. We've done 6 test releases so far. And it's been sent to OpenOffice.org for distribution this week. I'll be posting it all tomorrow after I get sleep.
Sometimes, the impossible can become possible, if you're awesome!
In the meantime, I did some tests with the new platform rc.
The new platform sets the variable Localeglibc, so that all characters are lowercase. That could be a issue and causes some bugs, IMHO.
For example: Gimp Portable
The condition $GIMPLANGUAGE="en_US" will never be true. The following code compares the variable Localeglibc with folder-names, so the bug has no consequence.
Well, MuseScore writes the language code to the registry. And there lowercase or uppercase makes a difference. "pt_br" doesn't work, "pt_BR" works. I'll have to add code which sets the variable uppercase.
Most of the launchers compare the variable Localeglibc with strings that have the first two characters lowercase and the last two characters uppercase. Maybe it makes sense to change how the menu sets the variable.
Thoughts?
Oh, and thanks for the ability to disable the automatic language switching. That's good for languages not supported by the menu too. Say an app could be started in hindi, but the user can't choose that language in the menu. Without disabling the automatic switching, the user can't use the app in hindi. That's not really end-user friendly.
PAP 1.5 English.locale says Localeglibc=en again. I think that was fixed since PAP 1.2 RC 2 or 3, but now it's official again
Consequence: Automatic language switching will fail if you launch an app which uses the Localeglibc environment variable. The apps will start in the system language (e.g. GIMP) or in the last used language (e.g. Dia).
John, we really need a correct table to avoid bugs!
Your bug report wasn't posted until after the Platform 1.5 was released, so it was too late to be handled.
It'll be fixed in the next release.
Sometimes, the impossible can become possible, if you're awesome!
see above, first report: 1st March :S
Edit: I just checked PAP 1.2 RC2 again, and the English.locale says Localeglibc=en_us. So this bug was fixed, only my report uppercase vs. lowercase was too late.