10
votes

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!

2
Just curious, what'd you end up doing? I'm in the same boat, and I'm curious if you ran into any problems with this approach (since it seems the most logical way to go). Also, do you have any examples/code of how you used this in your pages? I'm curious how ASP.net handled loading the right resource file with the non-standard names.rocketmonkeys
I did exactly what was described above and it worked great. We went so far as to write our own provider to replace the resource files with database tables as one of the requirements was end users had to be able to update the translations via screens. Plenty of doc on the later on msdn.Todd
How did you end up specifying which culture to "use". I want to do the same, and specify a custom culture in the Web.config but no luck. I posted a similar question, here: stackoverflow.com/questions/17217098/…Josh M.

2 Answers

6
votes

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.

2
votes

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.