How do you localize a database driven website

I’ve been playing with the .NET built in localization features and they seem to all rely on putting data in resx files.

But most systems can’t rely on this because they are database driven. So how do you solve this issue? Is there a built in .NET way, or do you create a translations table in SQL and do it all manually? And if you have to do this on the majority of your sites, is there any reason to even use the resx way of localization?

An example of this is I have an FAQ list on my site, I keep this list in the database so I can easily add/remove more, but by putting it in the database, I have no good way have translating this information into multiple languages.

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

In my opinion, localizing dynamic content (e.g., your FAQ) should be done by you in your database. Depending on how your questions are stored, I would probably create a “locale” column and use that when selecting the FAQ questions from the database. I’m not sure if this would scale very well when you started localizing lots of tables.

For static content (e.g, form field labels, static text, icons, etc) you should probably be just fine using file-based resources. If you really wanted to, however, it looks like it wouldn’t be super hard to create a custom resource provider implementation that could handle this.

Here’s some related links:

Method 2

For a given item in your data model, split out the description part into a localized table with a locale Id column (LCID).

So the table for Product would not in fact contain the products description or name, but only its hard and fast values (ProductId, EAN, NumberInStock, NextStockData, IsActive, IsPublished) etc.

ProductDescription then contains
ProductId, Name, Description, LCID

Method 3

I live in Canada so multilingualism is a big deal. I’ve seen two approaches. First option is to store all localized data for a specific record in a different table, linked to the original table by the primary key, and the locale. The second option is similar to the first, except that for each locale, there is a different table, with the locale as a suffix for the table name.

Option A

Item (ItemID, ...)
ItemLocal (ItemID,LocaleID,....)

Option B
Item (ItemID, ...)
Item_ENUS (ItemID,....)
Item_ENGB (ItemID,....)
Item_FR (ItemID,....)

A third option I thought Of recent, which would be really nice if a database supported it natively would be to store the values for all locals in the same field. And if the field was set up as varchar-multilocal, then you would have to access it by passing a parameter to specify the language. Nothing like this exists as I know it, but it’s something that I think would really make things a lot easier, and a lot more fluid.

Method 4

Currently, translation is not something that can be done automatically. The best way is to get a person to translate and use Nick’s methods to show the proper language.

Method 5

We use a mix of RESX files and Option A of Kibbee’s response. We created a simple tool to manage the RESX files online:
http://blog.lavablast.com/post/2008/02/RESX-file-Web-Editor.aspx


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x