The Microsoft .NET Framework enables developers to create software fully ready for localization and internationalization, through comprehensive machinery under the hood designed for, among other tasks, correctly interpreting strings given the current locale. This aids in quickly creating and using solutions designed for a broad range of cultures. But, when culturally-irrelevant string data is interpreted by these methods, code can exhibit subtle bugs and operate slower than necessary on untested cultures.

When interpreting strings, the canonical example of a culturally-aware type, sometimes flipping the culture switch causes unexpected results. The same strings can sort, case, and compare differently under different Thread.CurrentCulture settings. Sometimes strings should be allowed to vary according to the user's culture (for display data), but for most strings internal to an application, such as XML tags, user names, file paths, and system objects, the interpretation should be consistent throughout all cultures. Additionally, when strings represent such symbolic information, comparison operations should be interpreted entirely non-linguistically.

When developing with the 2.0 version of the .NET Framework, keeping a few very simple recommendations in mind will suffice to solve confusion about using strings.