The built-in localization system of the .NET framework already handles this fallback situation. You just install the satellite DLLs that localize your forms and controls and then, if the right one matches the user's locale, .NET will use it, otherwise it will fallback to the next related parent locale. For example, if your application's default language is en-US but you have provided an en-GB translation and an en translation, then the fallback is:
en-GB->en->en-US
i.e. when en-GB is not available, it looks for en, and if that isn't there it uses the default, en-US.
Therefore, when distributing, you can distribute just your main en-US application and then provide additional satellite DLLs for particular languages as, say, language packs. There is an attribute, SatelliteContractVersionAttribute, that allows your main application assemblies to indicate the satellite versions that it wants, which enables your localizations to work across assembly versions (such as if your assembly versions increment with the build - you can effectively ignore the build number).
MSDN has a lot of information on globalization and localization and how this works, even within the context of ClickOnce deployment. Check the Globalizing Windows Forms section.
Of course, if you have chosen not to rely on the .NET system for supporting globalized products, then you will have to come up with something that fits your chosen direction.