The easiest and most efficient way of localizing is the following which we have done:
1) Place all your strings in a XML file. That is have one NLS file (lets for simplicity call this NLS message file). Then place all your strings that need to be localized for different languages, etc., in this NLS message file. So your NLS message file would like something like this:
<MY_LIST_OF_NLS_STRINGS>
<MyTextBox1Name>Name</MYTextBox1Name>
<JobTitle>Software Engineer</JobTitle>
<FileName>File name</FileName>
<SomeTitle>The title of this page is %1</SomeTitle>
</MY_LIST_OF_NLS_STRINGS>
So in above we have 4 strings that are in the pproduct that need to be localized for different languages (i.e. MyTextBox1Name, JobTitle, FileName, and SomeTitle).
2) Develope a singleton class with a static method in it that given a XML tag name would extract its value from your NLS XML message File. So for example the signature of this class would be something like:
public static string GetMyString(string NLSMessageTagName, string[] args)
Where NLSMessageTagName simply is the XML tag in your NLS message file, and args is the list of substitution strings that will be used to replace %1, %2, %3, etc. (if any) in the extract value for the NLSMessageTagName.
3) In your code and when setting the values of any label, text, wizard caption, wizard title, etc., etc., etc., (and in general any text that needs to be localized) call the above API to set it. So for example you would say something like:
string args[] = {"Just a title"};
MyWizard.Page.Caption = GetMyString("SomeTitle", args);
Now the caption of your wizard page would be: "The title of this page is Just a title";
If you follow the above steps you do not need to worry about any .RESX translation or in fact worrying about anything about.RESX. All you would need to do is to tanslate your NLS message file, and have a version of th efile that is for English, one that is for Spanish, etc. The XML tags remain the same only their values are translated. The advantages of this is also that you do not need to re-build the entire product if you change any of the messages. All you have to do is change the message in the XML file.
Your implementation of GetMyMessage static API needs to also consider the local language under which the product is running (use VS .NET's CultureInfo for this purpose). The way you would organize your NLS message file is to place it in its respective languages directory for different languages (e.g. for US English your install will place it under en-US, or Spanish it would place it under es-ES and so forth). And then your GetMyMessage will automatically based on the info it gets from the CultureInfo locates the file, opens it once and then reads from it throughout the session that your product is running.
4) In all your GUIs make sure the Localized property is set.
Both ActiproWizard and Actipro SyntaxEdtior are NLS compliant supporting non-Unicode as well as Unicode characters (including Chinese GB character set).
And if you are worrying about the performance using an XML at runtime to retrieve NLS messages and texts, we did an extensive study of this and suffice to say that with an XML file having 100,000 strings, it takes 0.05 second to retrieve the value associated with a given NLS XML Tag. So nothing to worry about there.
Hope this helps.
