I'm trying to test some scripting that will run on non-English Windows installations. I'm trying to simulate that by installing the required languages and setting my locale accordingly.
However, when I run the VBScript, I notice that the language box in the task bar changes back to en-US, and the GetLocale function always returns 1033.
What else do I need to do to properly simulate a different locale?
Language box in the task bar has nothing to do with GetLocale.
If GetLocale is giving you 1033, your current system locale must be set to English(United States). Follow these steps to check (On Windows 7)
Go to Region and Language
Select Administrative tab
In the section Language for non-Unicode programs click on Change system locale
Once you change this setting, don't forget to do IISReset.
Based on my own research, it appears to be the "Format" setting in the Region and Language control panel that corresponds with the GetLocale value.
Unfortunately, this has no bearing on the display language for the OS, which is what I was really interested in.
Related
We have this problem where a Farsi UTF-8 text that is programmatically copied from an electron application, loses encoding when pasted into one specific application and is displayed as a set of ? characters. The issue persists even with manual text selection and copy command invoked via either context menu or Ctrl+C. Texts copied from other sources such as browsers or text editors are transferred just fine.
We tried clipboard API of electron. We also implemented our own helper to verify the issue is not with the clipboard itself.
We also prepended the text with UTF-8 BOM character before writing it to the clipboard.
One interesting observation was that once the text is pasted into some text editor and then recopied, target app received the text properly. We also noticed that changing the keyboard layout to target language when the electron app is focused, resolves the issue as well. In addition, we realized that Windows changes default keyboard layout to English when the application is launched.
Following on these clues, we configured NSIS bundler to set the default language to Persian so that maybe Windows detects it as default keyboard language as well. Description of the application shows Persian as the language but Windows does not respect it and reverts the language to system default upon launch.
We tried running a script on application startup to mimic a Farsi character keyboard input, creating temporary input fields, and a set of other hacks to maybe trick the Windows/application into properly handling these texts. Keep in mind we can't rely on user to perform idiotic actions on every application launch, to fix a problem that shouldn't exist in first place. That's why we need this issue to be resolved programmatically.
Right now the only solution that comes to mind is to force Windows to set the keyboard layout for our application to Persian via registry entries by some separate script that user need to run only once, or can be run after each installation. I'm not familiar with the windows registry entries. My searches came up empty and the results were focused on how to do it for the whole system, but we don't wanna mess with their whole system configurations since.
Any other suggestions regarding this issue is highly appreciated.
Other information that you might find relevant:
OS is Windows 7.
Target app is an accounting software and the vendor rejects to provide any support with the integration, so I have very little information about inner workings of that application.
html lang attribute of electron template is set to fa.
meta charset attribute is set to utf-8.
Application is bundled with electron-builder and NSIS.
I am working on a data set that contains Chinese characters. Stata displays these as gibberish and I need to be able to read these. I could not find a Chinese language pack for Stata. Does something like this exist?
I am using Windows 7 Professional and StataSE 13 (64 bit).
Go to Control Panel->Language->Advanced Settings.
Click into Apply language settings to the welcome screen, system accounts, and new user accounts.
In Administrative tab, under language for non-Unicode programs, change it to Chinese (Simplified). You might need to change system locale if your computer wasn’t initially set to be located in China.
For those who arrive here via Google. There have been substantial improvements since this question was answered:
See here for more information on setting locale in Stata 15 and later.
"If your computer language is set to Chinese (zh_CN) and its region is set to China, Stata will automatically default to its Simplified Chinese setting. To change languages manually using Windows or Unix, select Edit > Preferences > User-interface language... using Mac, select Stata 16 > Preferences > User-interface language... You can also change the language using the set locale_ui command."
(Windows interop here)
Background:
ConEmu is a program I just found, very cool, allowing a lot of features for interacting with the command line. However, it has a "Quake" feature where you would hit a key and get a console dropping out of the top like in most FPS games. I found a bug where it would not work properly depending on the language setting of the user. You can check the bug report if you want to know about it.
Question:
Is there a way to hook a callback into a specific key (not character, but specific key on the keyboard), regardless of the language setting the user has?
I've got a VB6 form with a ComboBox on it, which I'm trying to add a few single-character items to (specifically, 'A' through 'D'.) I can enter them into the properties box (using Ctrl-Enter to add new lines) and I get a box that looks like this:
When I accept the list items, however (by hitting Enter or moving focus,) it replaces all my single character items with squares:
This happens to all single-character items, but not any multi-character items I may add. The items are actually changed (it's not just a display issue), and show up as boxes when actually running the program as well. Obviously I can add the items programatically, but I'd rather do it during design-time for simple applications like this one. Is this a bug in the VB6 IDE, and is there a workaround?
i see .Disable all add-ins close vb and enter again test and after enable add-ins. in my case that fix it
You don't have a non-standard (or unicode) regional setting on your machine do you - try using English (United Kingdom) for both regional setting and keyboard setting and see if this helps.
When I wrote a VB6 app that used Arabic some time ago I had to change locale and reboot my box every time I wanted to edit the arabic strings in the resource file as it would screw up otherwise!
I had a similar issue many years ago, but not any more.
I think the fix was to install VB6 service pack 6.
Some of my Arabic users are reporting problems back to me with my application giving errors.
Common for them seem to be they are using Hijri calendar and TDateTimePicker control causing problems (but quite possibly it is the entire TDateTime and RTL that has problems, I am not sure)
The Hijri Calendar has a different year start/end which is not well suited for my application. (AFAIK, Hijri first became available in Windows7.)
I have problem reproducing the error because
1) I can't read Arabic making it much harder
2) I can only pick Hijri when Windows is set to Arabic (otherwise it is not a visible option)
Anyone here with the same problems? I Use Delphi 2010
Can I force my application into using standard calendar? (as solution) or can I force Windows to Hijri calendar on English Windows? (for testing)
In XP anyways, if you already have not done so, on Control Panel's Regional and Languages options dialog, go to the Languages page and first check the Supplemental Language Support checkboxes (Install files for complex script and right-to-left languages (including Thai)". For fun, check the East Asian languages one too, for later when you're going to want to check that chinese characters work properly.
Then, from the Control Panel, "Regional and Language Options" go to the "Advanced" tab and change the "Language for non Unicode programs" to an Arabic language.
Next you can go to date/calendar options and change to calendar type:
Hirji Calendar in arabic looks like this:
التقويم الهجري
Original source MSDN:
http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx
Additional pro tip: If you aren't already doing so, start using VMs for internationalization testing. Do you really want to do all this to your main workstation? Not me. I do this stuff in VMs.
You can use the Windows API function SetLocaleInfo, this would change the user's settings in the windows control panel which may be undesirable.