0

Problem

I have some resource files I've translated into a couple of languages and I noticed that some characters aren't being displayed correctly in my UI.

For example: Versión: is displaying as Versión:. I've ensured that I have the UNICODE and _UNICODE directives which, from everything I've read, should work as expected. What could be causing this?

Code

The code that's being called (and I did verify it's reaching this method):

static HINSTANCE _languageDll = NULL; //Setup in another function call

CString GetLangString(int resourceId)
{
    CString langString;

    langString.LoadString(_languageDll, resourceId);

    return langString;
}

Inspecting langString I can see it's loading Versión:

To see if it was a display issue I tried something similar to the following and it displayed correctly:

return CString("Versión:");

Looking through the code I noticed there's a define called LoadString in WinUser.h which switches between LoadStringW and LoadStringA based on the UNICODE directive. After some Google-fu I tried the following with no luck:

CString GetLangString(int resourceId)
{
    WCHAR buffer[256];

    LoadString(_languageDll, resourceId, buffer, sizeof(buffer)/sizeof(WCHAR));

    return CString(buffer);
}

I didn't let it return, looking at the debugger I could see it again loaded Versión:.

I'm at a total loss as to why this is happening. Could it be something with the resource files? I'm just diving into C++ so my skills could be better (AKA I'm a noob) so any help on this would be really appreciated.

Note: I'm taking over a project built by someone else so the reasoning behind why certain functionality is used is unknown to me.

Edit 1

The string in the original RC file is as follows:

STRINGTABLE
BEGIN
    IDS_STRING703           "Version: %d.%d.%d.%d"
END

And in the translated RC file:

STRINGTABLE
BEGIN
    IDS_STRING703           "Versión: %d.%d.%d.%d"
END
amura.cxg
  • 2,348
  • 3
  • 21
  • 44
  • 1
    Famous complaints in the R&D department of my company: _"Schei� Encoding!"_ :-D Sorry please, I couldn't resist. – πάντα ῥεῖ Mar 01 '19 at 19:11
  • What does the string definition look like in the .rc file? – Jonathan Potter Mar 01 '19 at 20:00
  • @JonathanPotter I updated the question with a snippet of what the original and translated RC files look like – amura.cxg Mar 01 '19 at 20:32
  • Has the translated .rc file been saved with a BOM at the start (`FFFE`)? If you change the string to `L"Versi\x00f3n: %d.%d.%d.%d"` (the `L` is important) does it work? – Jonathan Potter Mar 01 '19 at 20:55
  • @JonathanPotter There is no BOM at the start of the translated files, does that need to be there? Putting the `L` didn't have any effect (although there's no BOM so I could see that might be the cause) – amura.cxg Mar 01 '19 at 22:27
  • I ended up changing the encoding on the RC file (through NP++) to ANSI and now it works. Is the issue the original RC files had the wrong encoding? Is ANSI right? – amura.cxg Mar 01 '19 at 22:48
  • 1
    You should probably save it as a UTF-16 file. When you added the L did you also add the \x00f3 ? – Jonathan Potter Mar 02 '19 at 01:12
  • @JonathanPotter I'll give that a try, my build is broken right now so Ican't test these out. When I added the `L` I didn't have `\x00f3`, I'll give that a try as well. Do you know what the cause is? Is it because the resource has to be converted to Unicode and when it's in UTF-8 without the BOM it gets treated as ANSI? – amura.cxg Mar 04 '19 at 17:14
  • @JonathanPotter I was finally able to get it working and using the `L` prefix with UTF-16 worked as you suggested. If you want to create an answer I'll mark it as the solution – amura.cxg Mar 06 '19 at 20:24

1 Answers1

0

Make sure you save the resource file utf-16 format, not ANSI. And you can reference to this answer to learn about the format differences.

Drake Wu
  • 6,927
  • 1
  • 7
  • 30