> The reason is some languages use collation, you are dealing with the latin
> alphabet so I don't see an issue if you use collation precedence
Well, we might have to support Asian languages, too, so whatever solution we come up with, it will have to be flexible to handle any language.
> I am assuming you know you have to create tables for each language
> if you don't want to run into character conversion issues.
Well, I wasn't planning on creating separate tables for each language. I was thinking of creating a string table that contained all localized strings for the database.
First, I was going to create a reference table with languages/cultures. It would have just 3 columns:
- culture_id (primary key)
- culture_code (nvarchar 5)
- culture_name (nvarchar 50)
Examples of culture_code would be "en-US" and "fr-FR". Examples of culture_name would be "English (US)" and "French (France)".
Then I was going to create a string table. It would have have 4 columns:
- string_id (primary key)
- string_key (not sure yet what datatype this would be)
- culture_id (foreign key)
- string_value (nvarchar 256)
Finally, each table that had a string that needed to be localized would have a foreign key to the string table:
- widget_id (primary key)
- widget_name (foreign key to string table)
So, that's what I was planning.
But I'm new to internationalization, so please let me know if what I'm planning is wrong.