Multiple Domains Site Design Decision

Question

Hi, i am developing a project that its domain is meaningful in my native language. So i bought a second English domain for global usage.

My question is, how should i construct my site?

• Two different projects or one project with localization support?
• Two different databases or shared database?

What is my goal?

• Dont want to show English content in native site, vice versa
• I want to easily update site

If you suggest me to use shared database, could you please describe me design principle of database?

Thank You.

Answer 1

I'm not quite sure what could work for you, but I think that localization support would it be nice, and if you have a shared database you won't need to support to different databases and you won't need to add an extra database anytime you need to add a new language, and thinking about the application it would be easier just to if you want another language just to add it to your configuration and not create another project just to add that.

Answer 2

Typically for application code you ideally want to not fork for any reason including language. There are some quick things you need to watch out for;

• Ensure that strings are not hardcoded
• Store all datetimes in UTC
• Ensure that all user profiles have an associated timezone (you can grab this from the user's browser
• Try to ensure that your presentation is separate from your page content (i.e. use CSS, Master Pages, Templates or whatever your platform supports).

As for the database this depends more on the data your holding, for example if;

• You want users to share logins across both sites
• Knowledge to be shared but not necessarily localized (Wiki Entries)
• The sites are managing a shared resource (i.e. a single warehouse)

You might want to have one database.

However if you find the following are true;

• You don't want/need users between the sites to have cross over (think amazon.com and amazon.co.uk)
• Knowledge is wholly separate with entries in one language being irrelevant to the other
• The sites are managing wholly separate resources (i.e. two separate warehouses)

You might lean towards two separate databases. This will give you an advantage in scaling (though its not a silver bullet) and as long as the schemas are identical across the databases you will likely find that it's not too onerous.

One other option is to identify shared resources and split them into another repository (think user logins etc...). This can get you the best of both worlds but of course is a more complex design.

Remember all of this can be added after the fact it just becomes harder. Sometimes it's more important to get to market than it is to try and solve all your problems up front.

Good Luck!