All this technology is well presented in .NET. You created all resources in English, not using a single string constant for UI, all in resources. It provides Globalization:
http://msdn.microsoft.com/en-us/goglobal/bb688139[
^],
http://msdn.microsoft.com/en-us/library/401dkz3c.aspx[
^],
http://msdn.microsoft.com/en-us/library/ms788718.aspx[
^]. Later, you can add resources for other languages without re-touching original project, is special localization projects. The localized resource should be compiled in
Satellite Assemblies:
http://msdn.microsoft.com/en-us/library/21a15yht.aspx[
^]. They work using
fallback process:
http://msdn.microsoft.com/en-us/library/sb6a8618.aspx[
^]; the satellite assembly with the culture closest the the required culture is found automatically.
Final presentation of the application now is reduced to selection of required culture, which can be done automatically and dynamically, during run-time. Another option is to select culture in application configuration file and allow the user to edit it. See
System.Threading.Thread.CurrentCulture and
System.Threading.Thread.CurrentUiCulture.
Note: .NET application (thread) culture does not depend on system locale and can be changed at any time (of course the fonts should be able to render required Unicode code-point subset).
Important practical point is flexible UI design, not depending on text metrics in different languages. It may take serious experience.
There are more to it: date/time, currency, numeric formats: all these presentation aspects may be required to be culture-dependent, so they should be formatted using current culture.
—SA
Submit an article or tip