Foreign language display issue in CONNECT

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.

Parents Reply Children
  • 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.



  • Hi Peter,

    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).

  • It would be the right thing if bmake takes an option to define code-page

    Good idea! 

    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> …

    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?

    BeStringUtilities

    The MicroStationAPI BeStringUtilities class provides many methods to convert between string formats. For example …

    • Utf16ToWChar
    • WCharToUtf16
    • Utf8ToWChar
    • WCharToUtf8
    • Utf16ToUtf8
    • Utf8ToUtf16
    • LocaleCharToWChar
    • WCharToLocaleChar

    And some handy tools …

    • Split
    • Join

     
    Regards, Jon Summers
    LA Solutions

  • 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.

    Peter

  •  Example of correct display of Japanese text in tooltip, dialog, status.