I have migrated from old MDL application to the 64-bit MicroStation Connect environment. However there are still a lot of resources, such as tool dialogs and messages defined in traditional .R format. They were previously localized to multiple languages in MBCS (code-page) format and it worked in their own language platforms because those strings would display properly in non-Unicode applications if matching OS language settings.Now, CONNECT is Unicode based application, and mdlResource_loadWString is the ONLY API to get a string from .rsc (we still built a .ma file paired with .dll file). It never read in the string right. I tried to provide .R file in mbcs (flat file), UTF-8, UTF-8 with BOM. None of them worked properly. Each have a different result but all are wrong. I need to see a sample with Asian language (such as Japanese translation) paired and demonstrated how to support localization with the old R files.
Thank you...I am in a pressure to get things to work and I thought there may be people in the community who had the same issue and solution.
Hi Peter,
I tested with Chinese characters in .R file. It seems work fine. I just keep the "flat" character strings in .r file as below:
MessageList STRINGID_Messages = { { { MSGID_CommandTable, "Unable to load command table" }, { MSGID_ListBox, "列表框 行 %d, 列 %d" }, } };
The result is as below:
Hi Peter Wu,
I just wanted to follow up to see if Yongan.Fu's response to try modifying the SDK Example (examples\DialogBoxes\DialogBoxDemo) helped you to test and/or resolve this issue.
If the code you have migrated over is still exhibiting an issue please consider modifying one of these delivered examples that should also perform similarly to YongAn's approach.
examples\DialogBoxes\myapp\English examples\Elements\exampletool\English
Both SDK examples (and there are more) help to illustrate concepts discussed in the SDK help file (MicroStationAPI.chm) under parent help Topics: "Dialog Resource Integration" and "Localization and Internationalization Guide".
Thank you,Bob
Robert Hook said:
please consider modifying one of these delivered examples that should also perform similarly to YongAn's approach.
I'd like to mention that the language folder (English in the above example) should be left as-is. Create a new folder for your language. For example:
examples\DialogBoxes\myapp\Japanese examples\Elements\exampletool\Japanese
Set the language specification (langSpec) macro in the bmake file to select the Japanese resources. Copy the header and resource files from the English folder to the Japanese folder. Translate those in the Japanese folder. Now you can choose to build either an English version of your app. or a Japanese version.
#---------------------------------------------------------------------- # The following section builds any translatable resource modules for # the application. #---------------------------------------------------------------------- $(o)$(appName)str.rsc : $(langSpec)$(appName)str.r \ $(privateInc)$(appName).h
I think that stuff is documented in help, but it's easily overlooked in the feverish excitement of development.
Regards, Jon Summers LA Solutions
You are right, Jon.
I just tried to test if Chinese character can be displayed correctly in CE. So modified English resource file directly in example DialogBoxDemo.
Thanks Yongan and Jon for the information.
I wonder if I should save the .R file (and .H file containing the macros) as flat MBCS format, or UTF-8 encoding format (the later has two forms: one with BOM and one without). I tried all 3 ways and they yielded different results. MBCS would show the text like it is seen in western code page. UTF-8 without BOM will show wield characters. UTF-8 with BOM will show ?s for all Japanese characters.
Both the dialogs and the call to mdlResource_loadWString do not get the right Unicode string in the program.
Is there any special options in the building scripts that can make it do the right thing?
Note that the old R and H files worked in the old versions because they were treated as MBCS -- and only displayed properly in the matching OS language settings (language for non-Unicode program). I was testing on a Japanese Windows 10.
See the red arrows. This kind of result is when I stored the .R and .H files (in english folder) as MBCS (ASCII plain) format.
If I save the two files in UTF-8 format, then I get this:
I won't show another image, but if I use UTF-8 with BOM, it will show lots of ? in place of non-ASCII characters.
I am just following up on two items in this thread we did not receive feedback on to see if this helps resolve your issue.
Thank you in advance,Bob
I posted results showing that it did not work with all 3 kinds of encoding format of the R and H files: mbcs (mbcs is the plain text format that can only show properly in the matching OS language settings when you use Notepad), UTF-8, UTF-8 BOM.
See my post 7 days ago...
Hi Yongan.Fu,
Do you mind working with Peter on a reproducible "bad patient" test case (possibly based on a simplified version of his code) vs our examples that you (also) report are a "good patient"? If you suspect configuration variables needing set, don't forget to request "show configuration" live cfgvars too.
I update here two files (myappstr.r, myapptxt.h) in UTF-8 format.
https://app.box.com/s/seeo6i3c7omn9a2dzvywhb56rm3vp8z1
Do not know how to attach files here. So I put Japanese directory of the example MyApp in this box link for checking.
Peter
Thank you. I hope YongAn may be able to help you work through this as soon as possible and spot the differences/problems.
For .r resource file, I keep all things same with V8i. That are:
1. .r file format is plain text file with MBCS;
2. My windows' locale setting needs to be set to Simplified Chinese.
——————————————————————————————————
I further tested this and the result is: when you execute bmake, your Windows' locale must be Simplified Chinese. After generating .ma, even you changed your Windows' locate to English, the Chinese chars can als be displayed correctly. But if you bmake your project under a wrong Windows' locale, it will generate a wrong ma version.
HTH,
YongAn
I see. But then this means that bmake itself depends on system language setting for non-unicode applications. This is very difficult for me to carry out multi-language build process, as I need to support other Asian languages too. It would be the right thing if bmake takes an option to define code-page (since it takes MBCS as it did before, it would need codepage).
Peter Wu said:It would be the right thing if bmake takes an option to define code-page
Good idea!
Peter Wu said:bmake itself depends on system language setting for non-unicode applications
That doesn't seem right. Why can't the language resources be Unicode? MicroStation CONNECT is mostly Unicode internally. Why should language resources be different?
Take function mdlResource_loadWString(), for example. It reads from a message list of type RTYPE_MESSAGES. Here's the resource type struct from #include file <RmgrTools/Tools/rtypes.r.h> …
mdlResource_loadWString()
RTYPE_MESSAGES
typedef struct __messagelist__ { UInt32 1; /* Number of expected infoFields per string. */ struct messages { UInt32 infoFields[]; Utf8Char msg[]; } Messages []; } MessageList;
The message is stored as a Utf8 character string. That's Unicode, so why does the computer's language setting make a difference?
Utf8
The MicroStationAPI BeStringUtilities class provides many methods to convert between string formats. For example …
BeStringUtilities
And some handy tools …
This is exactly what I thought too. The new DLL we build is Unicode based. There is only one API to load a resource string and it should come in as Unicode! But it did not and I tried to provide the R and H files in all 3 formats and neither of them get me a proper string on call to mdlResource_loadWString. It seems to me that .R and .H files should still be MBCS (code page based), because my French and German all yielded right strings (they are in the same code page as US English, 1252).
I will try YongFan's idea by temporarily setting my locale to Japanese and build the MA file and see if it gives me the right stuff...if it works, at least it provides me a temporary solution. It won't work for automatic build script, for which we need to build for other languages, including Chinese (2 of them), Korean, Russian.
So, yes, if it turns out that bmake (or rather rcomp) depends on the system language setting for non-unicode program, then let's issue a request to improve rcomp to support specifying code-page option. I actually understand what it means -- because I build program to process multi-lingual localization and when you convert between MBCS (code-page) to Unicode you need to specify the code page and not using the system default, or it does not know how to convert. One example is Notepad (not Notepad++). If you open a MBCS format Japanese file in other than Japanese OS, it will not show the right characters.
YongFan,
Thank you for helping this matter.
I am writing to confirm that your method works. .R and .H file remain as MBCS files (the same way they are used for old versions V8i, XM, V8, J), and change system locale to Japanese, reboot, then rebuild the MA file for Japanese resources.
I have to say this is a painful process because a change to system locale requires to reboot computer. I have Simplified Chinese, Traditional Chinese, Russian languages to deal with... So I would like to request SDK to fix rcomp to support option to define code page, that way all MBCS code pages, UTF-7 or UTF-8 can be supported.
Example of correct display of Japanese text in tooltip, dialog, status.