Strings

UTF8 Strings everywhere. Using a typedef (ie, UTF8String) instead of just char * will let the compiler tell us about any mismatch in string encoding. We should still have unicode conversion capabilities (to and from).

Also, we will need auto-translating strings. Both in general and for a specific placement (specified by GUID of course). i.e.

XlatString mystring("[PLACEMENT GUID];This is some text", "en");

Then the translator can either specify he's translating the GUID or the generic text (for reuse). We'll also need something to handle printf-type stuff.

sooprcow> I'm not a fan of having the GUID stored in the string itself. Now that I think about it why use GUID's at all in this case. It seems kind of overkill, a simple integer (maybe setup via a #define) would seem to work just fine in this case. e.g

#define STR_SOMETEXT 32
XlatString mystring("This is some text", "en", STR_SOMETEXT);
XlatString mystring("C'est un certain texte", "fr", STR_SOMETEXT);

(translation thanks to babelfish so its probably wrong ;)

bizzeh> im not a fan of using GUID's in translations in strings at all. i think we would be better runing it like it was. ie _("some text here") ... which would automaticaly look up in the xml of the current language being used and pick the right translation, if none is found, just return the string you want to translate. though i think it would be better to use _WT instead of just _ since others use _ on its own and we dont want to confuse the compiler.

bas> the reason to have the GUID is because the same text may appear more than once but in different places, which might need to be translated differently, i.e. the word "free", which has multiple translations in many other languages. "class _" will probably go away because it confuses programmers; it doesn't confuse the compiler though, trust me. In fact that's why I specified XlatString? as a replacement. And yes, it's going to be a GUID. There is no need to reinvent the standard GUID implementation.

WaI> (moved out of ConceptSandbox?) I agree w/ sooprcow that having the GUID in the string does not make much sense, since it takes up more memory and is generally harder to deal with. Definitely, we should specify language according to the ISO 639 language codes (in a 2CC, or a 3CC, depending on our choice between the 2- and 3-letter codes, or maybe just a char* string).

//in xlatstring.h: (also quite possible for a wac to define new ones, so we don't have to def ALL of them.)
#define LANG_EN MK2CC('e','n'); // assuming we use 2-letter codes...
#define LANG_FR MK2CC('f','r');
  ...
//in a wac
#define GUID_MYSTRING { /*pretend this is a GUID*/ }
XlatString mystring(GUID_MYSTRING, ID_MYSTRING, LANG_EN, "This is some text"); //construct with default translation
mystring.addXlat(GUID_MYSTRING, ID_MYSTRING, LANG_FR, "C'est un certain texte."); //same would be called by language file reader after getting handle by GUID

bizzeh> check WinNT.h lines 841 to 1143 for how ms handle language stuff.. its like the idea of the MK2CC stuff. if we dont use the language stuff ms use, we could always use some of it for detecting the actual lang the current user is using and automaticaly output that if we have it