One thing I'd like to add to what [andarin2] said with options #3 is that there is all this talk of space savings. When you design a table, the sum of all the column widths are what the "potential" row size would be IF you filled in every column to its maximum value. However, with what we're talking about, having separate columns for each language would not waste more space than a 1-to-many translation table because you're only ever filling in 1-3 columns (if you want fall-back translations, say from es_MX to es_ES). However, I do agree that this approach does have more maintenance associated with it and even though SQL supports large numbers of columns (how many cultures are there?), it's probably not a good idea.

Using the 1-to-many approach (one translation table) would work, but you can only set 1 collation on the "Value" column and it needs to be nvarchar.

Having many tables (one per culture) would help with collations, however, it's maintenance is probably even more than the first option (multiple columns) and the JOINs would quickly become unmaintainable and complex as time goes on.