UI Localizer preview: possible bug?

[RobertoBozzolo]

To address runtime messaging you can have a separate message file (one per each language) and load the appropriate message from the file when you need it.

Alternatively, a specific callback could be used with messages in all languages and a general switch on the language used, something like this:

#define ENGLISH		0
#define ITALIAN		1

/****************************************************************************/
char * LocalizedText (int lang, int msg)
/// HIFN Returns a message in a specified idiom
/// HIPAR lang/The language to be used
/// HIPAR lang/Defaults to English if language unknown
/// HIPAR msg/The message to return
{
	switch (lang) {
		case ITALIAN:	// Messages in italian language
			case 1:  return "Sei sicuro ?";
			case 2:  return "Attenzione !";
			case 3:  return "Le modifiche immesse andranno perdute !";
			case 4:  return "Attendere l'avviamento dell'applicazione...";
			break;
		case ENGLISH:	// Messages in English language
		default:		// Defaults to English if unknown
			case 1: return "Are you sure ?";
			case 2: return "Warning !";
			case 3: return "Modified parameters will be lost !";
			case 4: return "Wait for application start up...";
			break;
	}
	return "";
}

 The application could then prompt messages in the following manner:

MessagePopup (LocalizedText (ENGLISH, 2), LocalizedText (ENGLISH, 3));

 which displays the message "Warning", "Modified parameters will be lost!"

[Steve_Macha]

Thanks Roberto.  Looks like tagged message files is the way to go.  But what about multibyte based languages, such as the eastern Asian?  Looks like the corresponding message tag file would contain message strings containing groups of bytes (Unicode or non-Unicode) where each group respresents a character.   Then prior to a MessagePopup( ) function as you have shown, there would have to be some manipulation of the string so that the output is an expression of Asian characters.  More description of the  mechanics of that process would be helpful.    Part 2 of the task would address the keyboard input of Asian characters.  It should be assumed that the system has been preset to the particular Asian regional language, and that the corresponding Asian character font has been selected.   And must we also assume that the system OS itself has been configured for the language?    Perhaps it unfolds that besides committing a PC to the specific language, it looks like the CVI developer must be proficient both in the default language (English) and the specific Asian language for development efficiency.  Sound reasonable?    As a side point, in working with the NI Localization Utility, it probable that the utility may have addressed some these issues.  If this utility was built using CVI, then it would be truly interesting to peak into its source code.

[RobertoBozzolo]

Well, we are going our of previous topic, it would be better to start a new discussion...

You could try a search in the forum for posts with multibyte keyword, and look at functions in ansiC >> Multibyte characters library.

I have no experience on those matter but I remember to have read several posts on this subject in the past.