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.
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.
Reference text: どうもありがとうございました
Copied to:
Notepad/Notepad++: displays it with no problems
LibreOffice Writer: it changes the font family to work, if you convert to Lucida Console, square boxes appear
Windows: displays it with no problems
Console: it needs the correct chcp and a font family (Lucida Console displays square boxes here too) which can display them if I am right
Is it possible to explain why Notepad can display any text in any font family and LibreOffice + Console cannot? Where is(are) the difference(s)? Is it possible to have the same behaviour on the console as the Notepad does for example?
Some Windows fonts have glyphs for many different scripts, some cover a few scripts, and many cover just one. (Fonts which support many scripts are sometimes called "Unicode fonts," which can be a misleading term. In other OSes, these kinds of fonts are more prevalent. Windows itself doesn't ship with any, though I think you get one or two with the Office suite.)
When you try to output text in multiple scripts using standard Windows functions using one of the well-known fonts, then Windows uses font fallback and/or font linking, which automatically switches between fonts as needed to output the whole string. Most programs, like Notepad and Notepad++, thus get coverage automatically.
I haven't read the LibreOffice code, but I suspect that when you select a font for a span of text, it sticks with that font, effectively preventing Windows's font fallback and font linking mechanisms from helping. This isn't surprising, since a WYSIWYG editor is likely to use lower-level APIs for outputting text in order to have more typographic control. But using the lower-level APIs means you don't get fallback and linking for free, so you'd have to implement it yourself, and that's a lot of extra work that may not be important to very many users.
The Windows console has a lot of legacy and limitations that persist for backward compatibility with older programs. The console mostly emulates DOS systems, which didn't have any sort of Unicode support and instead relied on "Code Pages," which are, roughly speaking, alternate mappings between character values and glyphs. Code Pages are geared at just one (or maybe two) scripts, so if you need characters from another script, you were basically out of luck. I think modern versions of Windows have hacked in some support for a pseudo code page that supports UTF-8, but I've never gotten it to work well and it, too, has limitations.
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."
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.
What's the best way to make a keyboard layout for Windows?
Specifically a layout that will appear in the 'Text Services and Input Languages' list and without buying expensive software.
I know about the Microsoft Keyboard Layout Creator but find it completely limited as you can't do simple things like remap the CapsLock key or the number keys.
You can build one yourself! A keyboard layout is basically a .DLL with a function that returns a table of assignments. The driver kit contains examples, and my Programmer Dvorak comes with source too (which is not derived from the DDK).
For remapping CapsLock or the number keys, use remapkey.exe found in the Windows 2003 Resource Kit Tools.
Keyboard layouts that show up in “Text Services and Input Languages” can’t remap CapsLock or do anything not supported by Microsoft Keyboard Layout Creator; the operating system just doesn’t support it. Anything that Microsoft can do with a keyboard layout, you can do with Microsoft Keyboard Layout Creator.
I realize that this thread is quite old and dead, but the answer provided is inaccurate.
You can do exactly what you want to do with KbdEdit. It is not free, but it is not expensive by any means, and there are several versions with varying features.
I would also like to point out that despite the claims of the highest rated answer, the operating system, in fact, most certainly DOES support a multitude of complexities and customizations which MSKLC can not understand, process or support.
There are—and always have been—MANY features and behaviors of keyboards which are possible in Windows but which are impossible with MSKLC.
In a number of cases it is possible to create as much as possible with MSKLC and then modify the source file in a text editor and then to build the DLL using the command line tools supplied with MSKLC. But it is my understanding that at a certain point—with certain features—those tools can not even be used to generate working keyboards.
At this point you could turn to the driver development kit, but that is beyond my scope.
Fortunately, there's KbdEdit! It is extremely powerful, easy to use and it can change any key on most any keyboard to any other key—except for the "Pause" key, which is a Microsoft imposed restriction, but even that can be circumvented with AutoHotKey.
Cheers!
did you check the new version of Microsoft Keyboard Layout Creator, I think you can do many things with this new version like remapping keys.
I am a fan of Auto Hotkey, a free, small, non-fuzzy windows tool to assign macros to keys. If all you want is a few special characters like proper “Quotation Marks” —or em-dashes— this is great:
#NoEnv;
SendMode Input;
!1::
{
Send „
}
return
!2::
{
Send “
}
return