title: Best way to design for localization of strings
body: <p>This is kinda a general question, open for opinions. I've been trying to come up with a good way to design for localization of string resources for a Windows MFC application and related utilities. My wishlist is:</p>
  
  <ul>
  <li>Must preserve string literals in code (as opposed to replacing with macro #define resource ID's), so that the messages are still readable inline</li>
  <li>Must allow localized string resources (duh)</li>
  <li>Must not impose additional run-time environment restrictions (eg: dependency on .NET, etc.)</li>
  <li>Should have minimal obtrusion into existing code (the less modification the better)</li>
  <li>Should be debuggable</li>
  <li>Should generate resource files which are editable by common tools (ie: common format)</li>
  <li>Should not use copy/paste comment blocks to preserve literal strings in code, or anything else which creates the potential for de-synchronization</li>
  <li>Would be nice to allow static (compile-time) checking that every "notated" string is in the resource file(s)</li>
  <li>Would be nice to allow cross-language resource string pooling (for components in various languages, eg: native C++ and .NET)</li>
  </ul>
  
  <p>I have a way which fulfills all my wishlist to some extent except for static checking, but I have had to develop a bit of custom code to achieve it (and it has limitations). I'm wondering if anyone has solved this problem in a particularly good way.</p>
  
  <p>Edit:
  The solution I currently have looks like this:</p>
  
  <pre><code>ShowMessage( RESTRING( _T("Some string") ) );
  ShowMessage( RESTRING( _T("Some string with variable %1"), sNonTranslatedStringVariable ) );
  </code></pre>
  
  <p>I then have a custom utility to parse out the strings from within the 'RESTRING' blocks and put them into a .resx file for localization, and a separate C# COM object to load them from localized resource files with fallback. If the C# object is not available (or cannot load), I fallback to the string in the code. The macro expands to a template class which calls the COM object and does the formatting, etc.</p>
  
  <p>Anyway, I thought it would be useful to add what I have now for reference.</p>