Custom Culture for client specific verbiage?

Question

Looking for some advice on the best way to implement localization along with client specific jargon on a asp.net site that will be used by multiple clients.

For example the labels on a form must vary depending on what client is logged into the site as well as what there language preference is.

So there will be a default set of verbiage/jargon for each client... and then each clients verbiage/jargon will be translated into languages they require.

I was thinking about created a custom culture for each client and then using the "built-in" localization features in asp.net and resource files.

So I might have a default culture... and then client specific cultures... and then client specific cultures translated to other languages.

en-US

de-DE

en-US-client1

en-US-client2

de-DE-client1

de-DE-client2

Does this sound crazy? seems like a fairly sound approach to me... but also maybe a bit of a hack... so I welcome any better ideas?

Thanks all for the help!

Answer 1

Actually it's not, it's a common approach - I've seen it quite a few times for e-commerce stores where the central store is a generic white label.

It's nice because ASP.NET supports localization out of the tin rather than you having to roll your own setting of text in every darned request, trimming viewstate from that, managing caching etc.

And don't forget culture specific information doesn't have to be in a resource file, it can come from a database too.

Answer 2

Yes, it's a little crazy. But only a little. ASP.NET will only automatically support localization up to and as far as the language and locale. I would recommend that you let it do that for the areas which are not specific to any client.

For client-specific labels, I would recommend that you combine the use of user controls along with code-behind to select the correct text from your resource file (if you're using VS, then use its built-in support for managing resources), and perhaps with the ASP.NET Cache (perhaps the @Cache directive) if you have limited combinations of what attributes can be used to select client-specific text.

Your approachs might look like a little less manual work, but is more likely to lead to problems that will take as much or more time to debug, as well as face challenges with compability in future releases of .NET.