localize by country

Question

Post reply

localize by country

foxjazzG

SSCrazy

Points: 2221
More actions
March 12, 2012 at 1:46 pm

#252431

Let's assume I have a database which has (many tables) two of which I will discuss.
I want to find the best way to do localization with a project client/server (silverlight) that I am starting.
I have a product table that has:
Product -- CountryCode,ProductID,PartNumber,StatusID
Status -- CountryCode,StatusID,Status
All products will be entered and shown with a countries different set. So all queries would have to include country code.
All links, CRUD would include countrycode.
If the silverlight user selects a different country, it would change the data they look at.
Is this the better approach or is it better to have a separate database for each country and have the app point to a database based on the localization and selection from the client.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

Henry Treftz SSCarpal Tunnel Points: 4207 More actions · Answer 1

It depends....

Are you going to need to take different downtimes depending on counrty?

Is the database going to get really, really huge if you include all countries in one database?

Would country qualification result in a two part key?

In general my answer would be no unless the first point was a major issue and perhaps the second point... You would likely index on country so that would not have a huge impact. You could even partition on country within those tables. The only real downside to seperate country databases however is maintenace and having multiples of the data database that you would have to push code out to.

Lowell SSC Guru Points: 323518 More actions · Answer 2

we have additional columns in one of our databases, instead of rows.

so the application ends up displaying the column [descrip_en-us] of , say Row 1 for a product,

[descrip_fr-FR] for french, [descrip_es-ES] for spanish.

it makes maintenance a little easier, because front end does a translat via google, and simply updates the other two columns;

it's alittle harder to do, but still doable, if you have a ROW for each language description.

Lowell

--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

Elliott Whitlow SSC Guru Points: 102402 More actions · Answer 3

In a previous life we had a multi-lingual app that made these assumptions.

1. Show the localized versions if possible

2. If not possible show the english version.

This involved a fairly complex query on the descriptions. However ALL the localized descriptions were contained in a single table for the whole app.

I probably would have built it similarly but I would have made sure that at least the English version always existed as opposed to incorporating it in every query.

CEWII

foxjazzG SSCrazy Points: 2221 More actions · Answer 4

Each country will ONLY see their data. If I log in as Spanish, I will not see any of the English data no matter where I go in the application.

When I input data, only the spanish users will see the data I change. Non of the other countries will see the Spanish data (just the spanish).

I don't need to translate anything, the users will populate the data based on their language, i.e. they will have their own set of records based on what country they say they are in (starting the application).

I am just wondering if it's easier to have 10 separate databases 1 for each country, or to have one database in which the data shown always depends on the country selected.

foxjazzG SSCrazy Points: 2221 More actions · Answer 5

Henry Treftz (3/12/2012)
It depends....
Are you going to need to take different downtimes depending on counrty?
Is the database going to get really, really huge if you include all countries in one database?
Would country qualification result in a two part key?
In general my answer would be no unless the first point was a major issue and perhaps the second point... You would likely index on country so that would not have a huge impact. You could even partition on country within those tables. The only real downside to seperate country databases however is maintenace and having multiples of the data database that you would have to push code out to.

YES every table would have a two part key.

Henry Treftz SSCarpal Tunnel Points: 4207 More actions · Answer 6

Considering what you have said, go ahead with the different databases assuming it does not make the coding more of a pain. I don't see a huge enough advantage one way or the other.