Multi-language site. How to organize it? Options

[zodiak]

Hi all.

I've been reading posts here for a couple of months. Great stuff. Congratulations.

My situation goes like that:
I have to build a site that is presented in English, German and Bulgarian.
And maybe soon it will contain Spanish and French.

So my question is how to do that?

I came up with one acceptable solution:
Make some language files containing the information, and depending on what language the user asks for loading the correct language file.
I've seen this kind of solution in a open source CMS.
So far so good, but I'm a little cautious. There will be lots of articles and you can see the difficulties. It will be quite difficult to format the text and pictures. :|

The other obvious solution is to build HTML pages for each language and transfer the user to the correct language pack. It sounds like building the Great Pyramid. :?

[DianeV]

Welcome to the forums, zodiak.

I'll be doing a multiple-language site soon. I'm thinking that, whether it's built with a database or static HTML pages, users have to land on some page somewhere. I'd far rather that all those pages exist, particularly so that search engines can pick them up (and people can find them).

Am I reading your question correctly? (And, yes, I can see the difficulties.)

[zodiak]

Yes you do read it correctly.

i've posted this in other forum here in Bulgaria, and the smartest answer was:
"Both have their advantages and disadvantages. You should pick the right one."

Are there other ways coming in your mind?

[DianeV]

Okay. If it were up to me, I'd make sure that all of the pages exist in each language that you need them. How to do that easily is another matter. I don't know that it matters whether they come from a database or not, but you'll need one if you're going to use a CMS.

I'm going to see if one of our programmer moderators can perhaps stop by here to offer an opinion. I guess what I don't understand is this:

Make some language files containing the information, and depending on what language the user asks for loading the correct language file.

... because the page had to be available in the first place (or the visitor had to be somewhere on the site) in order for the visitor to select a language. Could you explain?

[DianeV]

<added> Are you considering making basic information files that are then translated on the fly?

[dlumerman]

I suppose if you wanted to have the pages easily switchable from one language to another you could do it within a stylesheet, placing each language in it's own div tag, and remaining hidden unless selected.

Probably not the best (or easiest) way of doing it.

[bwelford]

The other obvious solution is to build HTML pages for each language and transfer the user to the correct language pack. It sounds like building the Great Pyramid.

Welcome to the Forums, zodiak.

I think you've got it right there. I think every visitor should get the same quality of user experience, whatever language they're using. That way no one feels they're regarded as second class. So you have parallel series of pages for every one of the languages. If you expect that some of your visitors may be multilingual and may suddenly decide to switch to one of their other languages in their surfing on the website then you should have language buttons in a standard position on all web pages. These language buttons switch you to the exactly equivalent web page in the other language.

I also believe that for human visitors and for search engine visitors you should not have an initial web page (splash page) where people must make the choice of language. Far better is to have separate introductory web pages for every one of the languages (possibly even separate domains or subdomains) with a more visible indication that other language choices are available.

[zodiak]

About the language files, maybe I didn't make (made?) it clear. I ment just the thing DianeV mentioned DB driven site with labels defined in language files. Not everything in those files.

dlumerman, I would say that the solution you recommended isn't what I'm looking for. Too much traffic.

bwelford, about switching languages I came up with the idea of a default language for instance English. I would use PHP to detect the browser's language if not detected or not available then I'll use the default language. And on every page there would be language buttons. No splash pages.

[thirstymoose_2000]

Depends on what the site is and what I think best suits my client's needs. Here in Canada we are bilingual (English/French) and many sites I work on have two versions.

For the most part, what we do is shadow the site and have different folders with static HTML pages. Sometimes we use ASP, and based on the language of choice tags are written. Either way is quite a bit of work. Which way we do it depends on what the client will need and what type of site it is.

Your idea of a default language is good and one used by many other designers.

In many cases, we follow a style guide and it states that we use a splash page to allow users to decide what language. Once you decide on the language you are taken to a 'home page'.

Another reason we choose to use this method is that people who find the site through search engines (which is at about 40% of visitors for gov sites) normally will end-up seeing the right language and will then be in the right folder.

We also keep a language button on top of the page just in case (it sends people to the other language version of the same page).

[Ruud]

Yup, language config files holding the names for menu items and such in each language. Content stored in the different languages in the database.

For the URL structure you either can go with a query variable (?lang=eng), pathinfo (index.php/eng) or a mod_rewrite (example.com/article/eng).

1) indexed by search engines, site can be ported to any server and will even work when the content may one day be written out statically
2) works for Apache but this type of URL is *officially* a malformed one. SE's have learned to deal with it though.
3) elegant but the more your site is used the less you would want to use mod_rewrite

[James]

Although it may not work for a multi-lingual country, you could use an IP/country database to work out which country a visitor may be from. Knowing that information, you could present the default language assumed for that country. You could then include links to the other languages that are available.

Using Ruud's query variable example (url rewritten would be my preference), you could then retrieve the correct text from an underlying data repository (database, files, or whatever). That way you have one set of HTML pages capable to delivering several languages with an easy way of switching.

Drawbacks would be if the data in the repositiory wasn't available or if you made an incorrect guess at the default language.

[zodiak]

I've read a lot about mod_rewrite and never used it. And knowing the capabilities of the hosting company (the hardware/visitors expected ratio) I rather would not use in the future.

About the URL query I'm wondering how many variables are safe to use.

And there is a 4): Session variables ? What do you think about sessions?

[James]

With regard the number of query variables, I would recommend that you try and use less than 4 to be safest.

You could use session variables. However, their use may make the solutions above not work well with search engine spiders. You are likely to want to have the site listed for each of the languages. If you use session variables to store data associated with the language selected, you'd need to look at the impact on your site listing within the search engines.

[zodiak]

Good point. Never thought of it.

[eron19]

I would use XML and XSL to do this...that way you only need to make 1 copy of each page, and the textual information would come from an XML file, based on some variable the user sets.

Not sure if this is the BEST way to do it, b/c I have done no research, but off the top of my head, that's what I would do.

[Tangaroa]

Since you have to write the content multiple times, why not have everything at the same page and use a ?lang= eng type of variable (like mentioned before). This way you can check the value of the variable and only show that content that corresponds to the value of the variable (this should work in any language but I'm thinking PHP here).
This way you can add a language link to every page that reloads the same page and checks the new value of the variable ?lang.

This could be easy to set up...I guess. Need to implement it myself (living in a bilingual country as well) and I guess I'll go that way...

Rgds

[allcdnboy]

Well, i found this site somehow through SearchEngineWatch and this post caught my attention. I have recently been employed by a Swiss company to build their website (www.sissel.ch) and have found a great solution to your query. My site is built to take advantage of two things, since this site was meant to be ported over multiple countries with multiple languages.
I use a database to seperate the langauge specific stuff and tried to remove as much diplication as possible without sacrificing speed. Anyway, with the help of such things in apache as:
forceType
ModRewrite
the directory paths get read and request the appropriate language based on those paths. For example, the first directory is the actual file that is being used, the next is the country (ch for switzerland) and then language (de) for german as in this example: http://www.sissel.ch/model/ch/fr/c-produit...praxisstuhl.php
... however:
http://www.sissel.ch/model/ch/de/c-produit...praxisstuhl.php
will produce the french result. But, I am big into optimizing for search engines, so the actual page that you would find through proper linking is:
http://www.sissel.ch/model/ch/de/c-praxisa...rollen_blau.php
so that the actual product, displayes in the URL.
Now, this link may seem a bit long winded, but i am trying to incorporate as many relavent terms into the url as possible, which is the category and subcategory that this product happens to belong to.
Surprisingly, this isn't really that hard, and I'm not sure why more sites don't do it (besides the obvious long windedness of it).
Another site that I've done is http://en.fitness.com and i have now managed to get 81,000 pages listed in google ... the site isn't language specific, but it uses the same technique.

I guess this post is a little bit long winded in itself ... sorry about that.

[mirpo]

Hi there,

If you have a commercial web site try to find a decent SEM consultancy.

If it is your private project - you need to struggle on your own :-(

Good luck

mirpo

[chrisclock]

In addition to the language switch, the page design, like look and feel, could be the other factor that webmaster should take into consideration. People in some country may not appreciate the color or layout of the site that the people in the other country like.

Web site translation is one thing, but Web site localization is another.

[TheManBehindTheCurtain]

Here I am giving the type of response that I usually dislike.

But just to present an alternative point of view: Everything you're talking about here is a technological solution to a business and communication challenge. If this type of approach works for you, great. But be prepared to encounter some other challenges along the way:

-- Business challenges. You haven't mentioned what the site's about. Informational? Marketing or eCommerce? Portal? One challenge global companies hit is that they don't always sell the same products in all countries. And in some countries, product A may be very popular, while product B sells best in others. What this means is that your entire information architecture has to change to present the right products to the right audience. I would assume that this could happen with a portal site or a informational site as well. Visitors from different countries may have different interests that can't be optimally served by presenting the same structure to everyone.

-- Communication challenges. If you're marketing products or at least in the business of persuasion, different audiences will respond to different types of information. In some countries, you must talk about the product, or service, or person's dependability and reliability. Others are more interested in know how the product works. Still others want to hear testimonials. Writing persuasively for, say, a French audience and a Japanese audience -- quite a challenge. And then let's say the original was in English, and then translated into the two languages.

That's just for starters. As global information architects will tell you, some types of keywords and metadata simply don't translate effectively from one country to another.

Of course, I know that from a practical point of view you may feel that you simply can't create sites optimized for each language. You can only address this issue with technology. But I will tell you that the experience of global companies is that eventually they have abandoned this sort of structured, programmatic approach. Instead, they simply have a strong template system that can generate some common look and feel and navigation elements, and then each site is structured, and content chosen, to fit the audience.

Even in your situation, someone will be doing the translating. Instead of assuming that all they will do is "translate" the same content into the same structure, simply give them a template from which they can build menus and pages. Then tell them to "localize" the content instead, filtering and presenting it in a way that makes sense for each country audience. All the work still has to be done -- it's just a matter of whether you're working to enforce structure, or to enable flexibility.

Just something to think about. I'm sure we'd all ove to see what you eventually come up with.