This is quite possible. First, you need to globalize the application. It should have flexible (fluid) layout to be independent of the strings in different languages; and all culture-dependent data should be placed in resources; in particular, all UI string data.
When this is done, you can add resource in different languages in separate projects. You don't even need the original projects, nothing except its resources. When this is done, properly,
satellite assemblies are created. They should be named and placed according some culture-based naming conventions.
This way, localization work can be passed to some other team without giving them source code of the original product, only the resource. (Of course, those people should know the use of the product very well and know both languages. So, they need to product itself for reference and testing.)
The framework automatically finds all satellite assemblies by current thread culture and UI culture. You can switch culture during run time. If some satellite assembly cannot be found, the
fallback mechanism finds the nearest available one, all the way back to original project resources, when nothing is found.
That's, basically, the essence of it. You will find further detail with MSDN links in my past answers:
globalization/localization problem in winform .net[
^],
globalization in winforms[
^].
—SA
Submit an article or tip