Most systems I've worked with have std::string markers in the code, the localization system generates a different type of immutable localized string that is accepted for the UI.

Currently we store our string internally as UTF8 and we do operations between UTF8 strings. The cool thing about UTF8 is that they work perfectly with std::string(or in out cause a lagacy string class that was implemented around char*) (as the 0 will be found only at the end of the file).
Under windows we convert to UNICODE/MBCS when needed(example is winapi specific function as OpenFile, SendMessage, CreateWindow...)
The unix based platforms already use utf8 as a native string.

Actually a good starting point would be to do what the guys form Autodesk Maya do with their MString (see MString::asChar method(it returns the string value in a platform native format)).

BTW a side hint:
In the MSVS in the debugger's watch windows if you type "mystringVariable, s8" the value of "mystringVariable" is going to be display as UTF8 string an not as a MBCS string ^_^

UTF8 works fine. Unicode sucks, no matter how you deal with it since it is way over-engineered and has way too many redundancies and special cases (unless you simply choose to ignore all these issues -- then Unicode is a "just works" thing), but UTF8 not only plays nicely with your 40 year old C string functions and is also kinda intuitive otherwise (think sorting), it also has no more quirks than necessary. Using stuff like wchar_t, you may end up discovering that wide characters have different sizes on different systems. Surprise, surprise.

I'm not overly fond of UTF8, as variable character sizes sound like a major annoyance for GUI display.

Well, with the "standard Unicode" strings under Windows, you have the worst of both worlds. You have wide characters, and you still have variable character sizes (since Windows uses UTF-16). Unless you use WinXP or Win2K, in that case you have "broken Unicode" (UCS-16). Insofar, UTF-8 is none worse, only better. Same amount of trouble, but takes only about 50-60% as much storage (for anything non-Chinese). Plus, English text is just plain normal, readable ANSI English text even in your favorite hex editor (no zero bytes in between), and even European languages are 80-90% multibyte-free, plain ordinary ANSI characters.

The only real inconvenience about UTF8 is that -- under Windows -- you have to convert all strings that you are receiving from the OS in some way, and you may have to convert any strings you pass to an API, too. Takes 10 minutes of consideration once when writing your API wrapper. Or you may simply not care and use filenames which work with legacy functions! After all, most of the time, as a game developer, you get to choose the file name. Choose wisely, and forget about it.

All in all, UTF8 is no biggie most of the time. Under Linux, UTF8 is the default anyway, so no troubles at all there.

There's no string class in my engine (except GUI as below), because you should never be working with strings :lol:

It's the trio of things that are commonly used, but an engine should never have to deal with: strings, files and quaternions.

If you want cross-platform internationalization, use UTF-8. You can convert UTF-8 to Windows wide strings (and the reverse) using MultiByteToWideChar (WideCharToMultiByte) with CP_UTF8 for use with Win32 APIs.

If you're only developing for Windows, with no plan for porting, just use Windows wide strings (UTF-16).

If you're not internationalizing your project, all this talk is pretty pointless; just enforce your native character encoding for internal strings, try to use the ANSI versions of Win32 functions, and if there is no ANSI version just tack L in front of the necessary string literals (IE L"I really hate that windows doesn't make ANSI versions of some new functions."). :)

There's no string class in my engine (except GUI as below), because you should never be working with strings :lol:

It's the trio of things that are commonly used, but an engine should never have to deal with: strings, files and quaternions.

At some level, you're going to have to deal with files, even if that means running everything on top of your own special snowflake custom HAL.

I'm not sure about the problem with quaternions either, as they're an immensely useful construct.

Now strings? Totally. In game code I try to reserve them as much as possible for UI/external purposes. And for the love of god, use UTF-8.