Forum Moderators: not2easy
I'm running (well, actually I just made and maintain them) a few bi-lingual websites and like to automatically deliver the contents in the clients preferred language (or, if not available, the plain default one of course). And yes, I already have the little flags on the pages to allow manual selection :)
I'm sorry if I'm a bit off topic or redundant, but this seems to be the place for receiving good information _very fast_!
Thanks already
david
Then set a cookie each time they change language, so the next time they come back, they go back to that specific site.
(I also just have learned that safari doesn't seem to be capable to hand over a language-request - I always get lang="en" no matter what language I run it...)
For example, on some of my Spanish sites, I get a lot of English speaking people coming through using spanish machines. Their keyboard is in Spanish, maybe even their windows settings, but they want the English version.
Yeah - that's the big minus with automatic apache content negotiation.
Summary - with that module assume you have in a directory;
index.html
index.html.en
index.html.en-gb
index.html.es
The module serves pages based on matching the extension with the language code that the browser sends. In my opinion it would be better to do the following: (planning to do this so appreciate opinions) (php just an example any server side - or even javascript could do this)
/index.php - if language code 'en' sent through redirect 302 - /en/index.html spanish, /es/index.html - no language code set - which would include the SE bots - serve a page with some basic english content and some content in your targeted languages with crucially - a large language selection - positioned obviously - with the lanugage name written in their native language eg. English, Espaņol, Magyarul etc etc - UTF8 or images for complex character sets.
This could be enhanced with cookies;
On sites with a large interest for expat communities - no automatic redirect would be preferable - internet cafes are usually set with the language code of whoever set up the PC's not the cliental.
coopster - the reason I suggested the cookie was so that the user can select a different language from the one his keyboard or system is setup in.For example, on some of my Spanish sites, I get a lot of English speaking people coming through using spanish machines. Their keyboard is in Spanish, maybe even their windows settings, but they want the English version.
That's fine, Sanenet, so you offer additional languages. But there truly is no need for the cookie. The best example I could offer is the same one that Apache displays on it's manual [httpd.apache.org] pages. No cookie is being set. I prefer English, but if I choose to read the manual pages in Spanish, I can do so, providing I can read that language ;) This is all handled by Content Negotiation and a bit of
prefer-languageand
RedirectMatchmagic. All of this is found in the default Apache
httpd.conffile. This is where I learned how to accomplish the task as well. It's slick.
A cookie solves this quite elegantly, the user only has to activate the language-switch when he wants to switch and not everytime he comes back..
We place a page on our sites instructing the user's of foreign languages how to change the settings in their browsers. Actually, this page is for the English-speaking sponsors of the project that have no idea that foreign-language-speaking visitors are smarter than they are and already know how to setup a browser. They haven't been spoiled by having their language set as the default as the rest of the English-speaking world.
However, if you have identified a necessity and want the user settings to be remembered, then either a cookie or some form of server-side storage requirement is a convenience. Cookies may work but you are going to have to set unique cookie information for every individual. I would argue that this is not the ideal approach. Think of two or more people sharing a computer -- how will you differentiate John Doe from Suzy Q? Since we are requiring authentication I would store the user's unique settings on the server-side.
<getting up on soapbox>
One other point...many web developers have taken the approach to separate content (particulary language variations of pages) into directory structures and a bunch of server-side scripting to move the user into the pages desired. I almost made this mistake. There is no need for this. Content negotiation handles this for you and you can keep like content written in different languages in the same directory structure on your server. The Apache manual pages once again are an ideal example. Although it looks like you are being pushed into a different directory for each language, you aren't (see the "magic" reference described earlier).
<gets off soapbox>
Spiders will still crawl your site. You can control the default page served when none is requested, or even if a language is requested but your site isn't setup for that language. It's also a perfect opportunity to start using extensionless URIs.
Content Negotation gets you started down the correct path. I would encourage some time spent reading and reviewing. Trust me, the rewards are worth it.
It's strong to call it a mistake - the redirection script is such a minimal piece of code I don't see how it could be considered a mistake.
Ok - so the module works great for static content - what happens when you start chucking in dynamic pages, content management systems, website applications etc? mixing in rewrite rules and more?
In short - I think that it will be useful for some sites - others - well - something that fits in with existing applications would be better.
What I do is create a page and have 2 languages in the HTML, one of which is hidden by my CSS using display:none
This display attribute is toggled by a menu item using server side variables. Means you don't really have dupe content issues, the only thing is that the engines sometimes think you are a foreign language site and won't show up using english results only.
Will either way work? Of course. Is one better than the other? My experiences allow me to confidently state that yes, I believe that http servers, well, Apache at least, are designed for content selection based on the specification and that variant maps will outperform redirection every time when setup and used as intended. My statement is not meant as arrogant or "any other way is wrong". I am merely offering to this community my experience in this area, offering what I have learned from application and practice.
I can assure you the approach works great for both static content as well as dynamic content. As a matter of fact, dynamic is what it is all about. It is a very rare approach that a site is developed without using some form of server-side technology to offer dynamic content to the documents. Server-side technology just makes the job so much easier.
