Storage and presentation of database data across multiple languages
Well, a lot of this depends on exactly what data elements need to be translated, and at the moment I think you might be focusing too much on technical specifics instead of where the need truly lies.

Given this:


  ASP.Net uses resource files to provide the interface in the local language


what elements need to be translated in the database?


Application / System lookup values? Probably not these since the UI is handling that via resource files.
User data? No, this wouldn't make sense. If someone fills out a form, they don't expect it to magically appear in 20 different languages.
Customer configured lookup values? Possibly, but they would be the ones supplying the translations.


Can you provide 1 or 2 examples of something that would need this structure? It seems that this structure is what would be used if one were not using resource files.

The only globalization issue I can see here is how to handle sorting and comparison according to each user's preferred language, given that many cultures have different rules, even if sharing many / most of the characters. In this respect, you will need to make use of Dynamic SQL because unfortunately you cannot specify collations dynamically (please vote for my suggestion to allow for this: Allow collation set by variable when using the COLLATE clause (at least in expressions) ). But for now (or possibly forever given the likelihood of that request being implemented :-(  ), you will need to attach the COLLATE keyword to relevant parts of queries (WHERE / GROUP BY / ORDER BY / etc) based on the current user's language. So one person might get French_100_CI_AS and someone else might get Latin1_General_100_CI_AS, and so on. This doesn't require multiple fields.

The only thing that different columns for different languages would get you is the ability to index the different collations (i.e. locales). So if there is a place that really needs performance, you can consider specifying the primary language as the collation of the column, and then create non-persisted computed columns that simply return the main column along with a different collation, and then index the non-persisted computed column(s).

If you feel that your app really will need to store multiple languages worth of a single item that would not be handled by the resource files, then please provide at least one, if not two examples. But even if there are some, I can't see how it would ever be all, or even most, columns. Things like customer names don't change based on what language they come from. I mean, I did adopt a Spanish form of my name for Spanish class in Junior High and High School, but that was for class. If I become a customer of a company in a Spanish-speaking country, I will still give them my real name. And the name of my street, city, and state won't change either.