I am using a seperate table to hold all the localized value for each table and lauguages. The table is something like:
LocaleID, SourceTableName, SourceField, SourcePKValue, Text
'en-US', 'dbo.Author', 'Name','5','Rob'
In the stored procedure where localized value is reuqired to return, use the following function to retrive the value:
This method can support different languages without changing the code.
Why not add "language" to your PK? Table could be like:FLD (PK): IDFLD (PK): LanguageFLD: TextValue
Then you'd have records likeA - English - English Text AA - French - French Text AA - Spanish - Spanish Text AB - English - English Text BB - French - French Text A
You should have a lookup table containing the languages which has referential integrity to the Language column in your data table. Doing it this way, if you get a new language you just add a single record to the lookup table (say German) and you can populate the new text values into your data table without any DB structure changes. Additionally if you find you're storing data values for one language a lot more than another, you're not ending up with a lot of records containing empty values (which you would if you have records containing a field for each language).
My two cents...
You certainly can add a language column in your PK. The problem is that you will have too much redundancy for non-text columns, and it will be difficult to maintain the table.
If I am not wrong, the original question is to expose the same information in different languages.
For tables that accept user input, the language column is a good idea. But it's not necesarily part of PK.
Try these links for localization in .NET because most .NET application localization is in XML. Hope this helps.