Multilingual website

[emilyo]

I have a website:

http://www.epicmmtbgreece.com

My partners (and I) would like to make it so you could click on a flag and it would translate into a different langauge.

We need (would like) translations in French and German, but also Greek, which would be slightly more difficult because of the different alphabet.

I have people who could do the translations for me and I like Nick (webmaster)'s idea in this thread:

thread333-939282

Just not sure how I would go about creating the database. I know zip about asp, php etc, so mickey mouse replies only.

TIA guys.

Emily

----

http://www.EpicMTBgreece.com

http://www.EppingForestEpics.co.uk

 

[damber]

Emily,

Keeping the response simple may lead to a vague answer, so if you need more detail please post back.

There are different requirements for Language Translation on a website:

1. Multi-Lingual Framework and Fixed Content
This is where you want your field names, menus, Titles and other fixed content to be translated between the supported languages. This is the relatively easy part (though don't take it lightly). To do this you would build your site in such a way that text based content (even image sources) are made dynamic via the use of a function/variable in the page that gets replaced at runtime by the ASP script for example:

<p>
<%=fGetLangText("Hello",Session("lang-code"))%>
</p>

When in French Mode would be replaced with:

<p>
Bonjour
</p>

When in English Mode:

<p>
Hello
</p>

This would come from an array of keywords which hold the translated content. There would be multiple arrays that hold the different languages (e.g. one array for English, one for French, etc). Here is an example of how another Tek-Tips user has done this:

http://www.tek-tips.com/viewthread.cfm?qid=1026021

(the example function above (fGetLangText) would probably access the Application object and lookup from a dictionary type array based on the language and the keyword - if you want an example post back)

2. Internal Dynamic Content Translation
This is the slightly harder bit and has various approaches. It is essentially the translation of data that is stored in a database that has been produced under your company's control (e.g. news bulliten) meaning that you can have it translated manually before deployment. This requires the database design to handle multiple instances of this text for the multiple languages. You can either add an extra column for each language (which doesn't scale very well). Have a separate database for each language (difficult to maintain, more complex), a separate table for each language (same again - complex and difficult to maintain), or a separate row for each language (which is usually the most elegant solution.. but it depends greatly on the datamodel you have implemented). The multi-row would require the addition of a small varchar field to hold the language identifier for that row (e.g. en / fr / es)

3. External Dynamic Content Translation
With many websites, external users can add content (comments, posts, profiles etc etc), which means that they will type in the language of their choice. This is the most difficult to translate and is rarely done due to the inaccuracy of automatic translations and the cost of manual translations. You can either build your own translator software for this (more complex than you would think), buy a software package (relatively expensive and still not 100% accurate) or use a service from another company (again, expensive, not 100% accurate and adds latency to the response).


With all that in mind, you need to tie this together. When a user first visits your site you need to read their User Agent properties (e.g. their accept language) and if it is determinable then add that value to their Session() variable, otherwise ask them to select a language from a list (make sure this is done in each language!).

Whenever they hit a page you will use this language code (e.g. en/fr/es) to select the relevant language set from the global array list and replace all variables on the page that match up - either by pre-parsing the page, dynamic variable generation,direct access to an Application variable dictionary object or via a function (which would in turn access the Application variable) - so if they have 'en' in their session they will see the English version of the text when it is displayed.

Whenever you do a lookup from the database use the language code to select the appropriate row - just be careful when doing counts and the like, as multiple languages will show up as multiple rows (so a natural key of the PK and the language code may be helpful).

For more exotic languages you need to consider the Text Encoding within the page header, and also the Locale (LCID)/CODEPAGE settings at the top of the ASP page.

Sorry this is somewhat vague, but you did ask for 'mickey mouse' replies.

Hope that helps.

A smile is worth a thousand kind words. So smile, it's easy!

 

[emilyo]

Hi Damber

That's just what I wanted.
It is going to be tricky isn't it?
I guess the easy (non techie) way would be to have four websites, but I don't really fancy that - nightmare for updating everything.

I guess I will have to read up on all this stuff - I am very lazy as you can tell. I have a love-hate relationship with IT.

I will get back with more specific questions when I have put in some leg work.

Thanks again mate.
Emily

----

http://www.EpicMTBgreece.com

http://www.EppingForestEpics.co.uk

 

[damber]

No problem Emily, I just realised I missed that option off my list - but yes, you can have separate websites which are managed separately... though your back-end data integration needs to be reasonably tight, so that any content produced on 1 site is available on the others. The biggest problem here is version control

To do this you should AT LEAST separate your content from your presentation and structure, so that you don't need to update 4 different ASP pages when you want to change the layout or add ASP code. This can be done with XML and XSLT and ASP, but that again adds complexity and XML/XSLT add a bit of processing overhead - so for high volume sites tend to become a little inefficient.

Be careful if you do go down that route though - it is easy for the versioning to run away from you and become a support nightmare.

Good Luck...!



A smile is worth a thousand kind words. So smile, it's easy!