Globalizing runtime generated assemblies

Create a separate satellite assembly for each culture. This has two benefits:

You can build all of the assemblies in one go, and have a definitive file for each version number and filename combination, rather than it also depending on the culture.
You can have multiple assemblies in the same installation, and base the language to use on the system language, or a user preference etc. This will make development and testing significantly easier, as you won't need to keep rebuilding and copying files around just for the sake of changing languages.
It's how .NET i18n is designed to work. While I'm not an expert on .NET i18n ("read Guy Smith-Ferrier's book" is my best advice!) I generally find that frameworks work best when you follow their expected model.

Even if the final part of "building the satellite assembly" is done at runtime (can you do it at install time instead?) you still get the second and third bullet advantages at least. It also means that if you ever do go the more normal route of supplying the satellite assemblies to start with (instead of building them on the user's box) you'll have less to change.

Apologies if I've misunderstood the question though...

Thanks, that's a good suggestion although from recent discussions, it looks like we will want to add languages after deployment. That said, your suggestion may well still work as we could re-deploy any satellite assemblies whenever we add a language.

Jeff Yates 2009-01-15 05:19:58

I am certainly doing all I can to leverage the way .NET wants to work. Our file format somewhat hinders this and I have to come up with a process that doesn't require a full rewrite. Currently, my thinking is very similar to yours: have resx files for each language and build a per language satellite

Jeff Yates 2009-02-02 15:15:48

...assembly. I would love to do the build on install, but we have certain requirements to refresh the assemblies at application start-up, so this isn't currently possible.The framework for distributing and selecting a language is in place for the remainder of the application, using .NET support...

Jeff Yates 2009-02-02 15:16:57

...wherever possible. The main difference for this problem is how we distribute the additional localizations. My current thinking is to ship the resx in some encrypted format (to prevent tampering). The format would also need versioning to match with the main file.

Jeff Yates 2009-02-02 15:19:53

Yup - that means your period of "not doing the normal thing" part is as short as possible.

Jon Skeet 2009-02-02 15:26:12

While this covers the deployment/integration of localisations, I have one additional issue. Our panels are created by a designer that we have written, and I haven't been able to get the Localizable extension property to appear that forces the designer to put localizable values into resources. Ideas?

Jeff Yates 2009-02-03 04:24:28

No, I don't know anything about that I'm afraid... I suspect you'll be best off asking a new question for that one, to gain more knowledgeable readers :)

Jon Skeet 2009-02-03 07:32:17

ansaurus

tags:

views:

answers:

Globalizing runtime generated assemblies

related questions