As I came to work today, posted on all of the doors and walls was a notice stating that one of my associates was turning 40. An anniversary of birth that most of us do not or will not want to be reminded of. Then it hit me, this column (26 July 2001) marks the one year anniversary of sharing my answers to your international questions via this column. I have received a lot of good questions that I hope have helped you all.
I thought about publishing some of those questions again, but realized that they are already accessible to you via my column's home page ;–), So here are the answers to the 13th (unlucky for some, lucky for others –– me included) set of questions:
We are using Access 2000 to develop a software package sold internationally. Following normal convention, most of the support files are installed to the 'Program Files' directory.
Is there a universal way to determine the actual directory name to point to?
Moe
Dear Moe,
In most of the localized versions of Windows, the system directory names are also localized (translated) from one language to another. The best way of retrieving the actual folder name at run time in a consistent matter is to use the SHGetFolderPath Win32 API. This API allows you to retrieve any system folder name (user profile, documents and settings, etc.). The following code snippet shows how to use SHGetFolderPath.
// SHGetFolderPath can work everywhere SHFOLDER is installed.
HMODULE hModSHFolder = LoadLibrary(_TEXT("shfolder.dll"));
if ( hModSHFolder != NULL )
{
(*(FARPROC*)&g_pfnSHGetFolderPath =
GetProcAddress(hModSHFolder, _TEXT("SHGetFolderPathW")));
}
else
{
g_pfnSHGetFolderPath = NULL;
}
if (g_pfnSHGetFolderPath != NULL )
g_pfnSHGetFolderPath(NULL, CSIDL_PROGRAM_FILES,
NULL, NULL, szSystem32);
else
szSystem32[0] = NULL; // Note: at this point, if you fail to
// get a handle to shfolder.dll, try
// checking out the registry for that
// information at:
// HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion
OpenFileName.lpstrInitialDir = szSystem32;
The good thing about SHGetFolderPath is you can use it on Windows 95/98/ME or Windows NT/2000/XP platforms. Note that the above example is Unicode based, if you want to use an ANSI based version for Windows 9x, you should use SHGetFolderPathA.
I would like to build a multilanguage web application that passes data to and from a database.
By sniffing the user's browser, I can display the front end pages in the language of the user: Japanese, English, Thai, Esperanto, whatever.
Problems arise when I want to display sorted text in a form's drop–down box. A Japanese person would like to have his data sorted in a different way compared to an English person. What can I do?
any ideas
Dear Any Ideas,
In order to accommodate a user's cultural preferences, you'll need to sort the list yourself. Having a Web client, you may prefer to sort the list on the server, store the sorted data in your database, and then send it out sorted.
You also may do it on the client (use the localeCompare() function of JavaScript, for example), but the results will depend on the locale settings of the client machine which will not necessarily match the browser settings.
The second solution may also be slower when long lists are to be sorted; so I would recommend the first solution. I know this is what Hotmail does to accommodate their user's cultural specific sorting preferences.
We are developing a mulitlanguage application which runs both on Windows and DOS. There are not many issues for Windows that we can't solve, but the real issues are with DOS.
Since the DOS application cannot use big amounts of memory, it is optimized and restricted, and thus we cannot use Unicode to display text.
In our application, we have a dictionary which we have stored in an Access Database in Unicode format. The problem comes when we have to convert from Unicode to ANSI to display text on the DOS system.
On the MSDN network they suggested the use of the "strconv" function but it doesn't seem to work. It converts only a few chars and the others come out as only the "?" char.
the unconverted
Dear Unconverted,
When you use strconv, do you pass anything in the optional third parameter (see below)?
StrConv(string, conversion, LCID) // LCID = Locale ID
The question marks that you are getting usually mean that the Unicode to ANSI conversion is not using the correct conversion tables determined by LCID. If you do not use the third parameter (LCID), StrConv gets its LCID from the system Default locale which is the locale your system was installed with (this locale can also be set on Windows 2000/XP).
Thus, if you are trying to convert Japanese Unicode strings to ANSI on an English system, you are going to get the '??'. StrConv assumes you are trying to convert the text to the 1252 code page (or what ever code page is associated with the current system locale) and it does not know how to convert the Japanese Unicode strings. That is why you might get the '??'.
Also, if you are not sure what the correct LCID should be, go to the following site:
http://www.microsoft.com/globaldev/nlsweb/default.mspx
It will give you a list of languages, their associated LCID's and their corresponding OEM codepages.
I have a string that the user inputs in a text box and I want to convert it to a DWORD. Today I do this.
WCHAR EditBoxString[ MAX_PATH ]; DWORD EditBoxValue; GetDlgItemText( hwndDlg, IDC_MYEDITBOX, EditBoxString, MAX_PATH-1 ); swscanf( EditBoxString, L"%u", %EditBoxValue );
Will this work with all the supported number formats in the system. If not, which API should I use to do the conversion.
unconverted II
Dear II,
No, this will not work for non–European digits where basically you get a Unicode code point. Here is the result for Arabic (which uses Indic digits) and European (which uses Arabic) digits:
For Windows NT/2000/XP, you can use FoldString with the MAP_FOLDDIGITS flag to convert all the digits in your string to the Unicode digits 0–9 (0x0030 – 0x0039). You can then run your atoi converter on that string to get your DWORD value.
I am using a Windows 2000 server with Office 2000. Both are the Multilanguage User Interface (MUI) versions. When I upgrade my Internet Explorer 5.1 to 5.5, the Windows Explorer and the other applications are drawn back to my national (single) language version. Does a multilanguage version of Internet Explorer 5.5 exist? Where can I download/get it?
VM
Dear VM,
Sorry about this problem, but fortunately it's relatively easy to fix. The files are posted on Windows Update:
http://windowsupdate.microsoft.com
Click on Windows Update Catalog (on the left bar). On the following page click on "Find updates for Microsoft Windows operating systems." Select your operating system from the list, leave lanugauge as English. Click on "Advanced search options". Enter menus and dialogs for internet explorer as keywords. Check the box beside Multi-language Features, and click Search. On the results page that appears, click on " Multi-Language Features (91)" (may have a different number). Select the language of the MUI package for the version of Ineternet Explorer you are running. After you install the new package, log off, and then log on again for the change to take effect.
If you would like to read more about this you can check out the Knowledge Base article Q264550 at http://support.microsoft.com.
With the new Office XP now out, is there any place I can find additional international templates, clips, help articles, etc.?
globally speaking
Dear GS,
As a matter of fact, the international office group just released a new web page at:
http://office.microsoft.com/worldwide/
that has links to the many different languages Office/XP supports.
Now on to year 2 and my next anniversary. Keep those questions and comments coming in. See you next time
Dr. International
Windows Division