0

I am working on a .Net software product that consists of multiple applications of various sizes and dozens (potentially hundreds) of assemblies. Everything must be translated into several languages.

Whereever I look, the suggested way to localize strings in .NET is to create satellite assemblies with resource strings. Of course, all those examples simply show one assembly, and how to make localization work technically. My problem is, that in practice I don't see how this should scale to a large set of assemblies.

If i simply duplicate the approach for each assembly I end up with a really big number of satellite assemblies to maintain and deploy, and I have to keep track of one and the same string/translation in every assembly that requires it. Everytime a translation changes, I have to locate all uses of this string throughout all my assemblies, and modify it.

Everytime I need to update my translations, I need to extract everything from the multitude of resource files, send it to the translators, and then spread their results again to the correct resources. This can be done of course, and I assume some of it can (and must) be scripted. However, it doesn't strike me as especially smooth and efficient.

One alternative I can think of is to create a dedicated translation assembly (with satellite assemblies) that serves as a central repository for localized strings. All translations of all strings of all assemblies would go there, and it would be referenced by each and every assembly in turn to spit out the translations.

This seems to make maintenance a lot easier, but of course this central assembly with its enormous set of resource strings would have to be deployed along-side even the smallest of my applications which actually would need only a tiny fraction of them. Moreover, this assembly would have to be frequently changed by many developers which would lead to a high risk of conflicts.

My question is:
How is the approach of localization via satellite assemblies supposed to scale to large software projects with many assemblies? What are the suggested strategies and best practices?

David Ansermot
  • 6,052
  • 8
  • 47
  • 82
Peter
  • 43
  • 7
  • To quote [MSDN](http://msdn.microsoft.com/en-us/library/5839we2z%28v=vs.110%29.aspx), "The common language runtime supports a **satellite assembly resource model that separates an application's executable code from its resources**. For more information about implementing this model, see [Resources in Desktop Apps](http://msdn.microsoft.com/en-us/library/f45fce5x(v=vs.110).aspx)." (**emphasis** mine); As such why would you need to update your code if a translation changes? After all, the resource name can (and should) stay fixed across locales... – Rowland Shaw Oct 10 '14 at 07:56
  • No need to update code of course. What I meant is: There are numerous strings that are repeatedly used throughout large parts of the application. If each assembly has its own translations of these strings in its own satellite assembly, effort is required to keep those translations in sync. – Peter Oct 10 '14 at 07:59
  • Sounds more like you want to refactor /consolidate your assemblies, or use tools to build the duplicate resources. Of course, a good case study of how it can work is the .Net framework itself. – Rowland Shaw Oct 10 '14 at 08:03
  • Are you saying, that a situation with translations shared by multiple assemblies should be avoided? I see, that this would of course resolve the problem. I assume this is also the way the .Net framework does it. However, If I do that, I end up with one humongous assembly. This is just not possible in my case, for various reasons. Which tools, and how would they help me? – Peter Oct 10 '14 at 08:42

0 Answers0