homepage Welcome to WebmasterWorld Guest from 54.198.135.17
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / WebmasterWorld / Content, Writing and Copyright
Forum Library, Charter, Moderators: not2easy

Content, Writing and Copyright Forum

    
Automatic Language-delivery
how-to? Where to learn?
davidbraun




msg:920992
 1:41 pm on Feb 10, 2005 (gmt 0)

Hello
I've read several Articles touching the topic of "automatic language delivery" (according to the browsers settings), but couldn't find what I am looking for: What is required to get this beast to work? Where's the information/documentation?

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

 

Sanenet




msg:920993
 1:47 pm on Feb 10, 2005 (gmt 0)

When the user hits your site for the first time, check to see what their default language setting is (should be in the CGI.accept_language header). If you have a compatible language, redirect them to that page.

Then set a cookie each time they change language, so the next time they come back, they go back to that specific site.

davidbraun




msg:920994
 2:46 pm on Feb 10, 2005 (gmt 0)

If I get it right, this is server-side, isn't it?

Sanenet




msg:920995
 2:54 pm on Feb 10, 2005 (gmt 0)

Yes, although you can do a similar thing using javascript, try out a script source like javascript.internet.com.

davidbraun




msg:920996
 5:25 pm on Feb 10, 2005 (gmt 0)

It's so simple one wouldn't believe it's true!
Thanks so much!

(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...)

coopster




msg:920997
 7:04 pm on Feb 10, 2005 (gmt 0)

No need for any cookie setting at all if your web server is capable of Content Negotiation [httpd.apache.org]. You develop the pages, the server dishes up the correct document based on the user's browser settings.

Sanenet




msg:920998
 11:51 pm on Feb 10, 2005 (gmt 0)

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.

davidbraun




msg:920999
 5:40 am on Feb 11, 2005 (gmt 0)

I'll second it - Safari for example doesn't seem to be "accept-language-sensitive", at least not to the java-script-solution. (I guess Safari tries to sync with the systems language preferences, but always answers "me english" when asked)...
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...

conor




msg:921000
 1:33 pm on Feb 11, 2005 (gmt 0)

Be careful that spiders can still crawl your site - they dont have a language setting ;)

gethan




msg:921001
 1:56 pm on Feb 11, 2005 (gmt 0)

> Be careful that spiders can still crawl your site - they dont have a language setting wink

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.

davidbraun




msg:921002
 2:05 pm on Feb 11, 2005 (gmt 0)

I'd do the whole plethora...
First, redirect (it is my guess that most users sit in front of their own, well-configured, coputer). Second, offer them a "switch-language"-button (or pull-down for extensive selections), and third, as mentioned above or elsewhere, cookie every manual language-switch to avoid the user to be redirected to the browsers language-preference at every click...
(Thus, spiders would also be offered the hard-coded selection-tree, wouldn't they?)

coopster




msg:921003
 2:41 pm on Feb 11, 2005 (gmt 0)

We have two different situations here.

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-language and RedirectMatch magic. All of this is found in the default Apache httpd.conf file. 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.

gethan




msg:921004
 5:37 pm on Feb 11, 2005 (gmt 0)

re: soapbox

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.

bateman_ap




msg:921005
 6:03 pm on Feb 11, 2005 (gmt 0)

I have a completly different way of doing this, whether the engines penalise it or like it I am not sure but users like it and thats good enougth for the moment.

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.

coopster




msg:921006
 5:40 pm on Feb 12, 2005 (gmt 0)

Mistake may be a strong word, but I'm not sure how else to put it ... misguided approach? There are always other factors outside of just the code or a minimal redirect statement. Performance, site structure and site maintenance are some that come to mind.

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.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Content, Writing and Copyright
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved