Search

I would like to see the mechanism of automaticly displaying content in the visitors language, as here extended to doing this via content type mappings, instead of via an url param. So resulting in apache content,negotiation (with ofcourse a dropdown override to change languages manually).

Along these same lines, it would be sweet if we had an extension to just load all the HTTP request headers into the param pool.

Where would I look if I wanted to put that together?

ashooner: Just use the Global Param Loader, with “return($_SERVER);”

Edit: oh, do arrays work as params?

Oh, wait, does that mean to implement content negociation I only need to filter the datasource by a param ‘country’ and dynamically fill it with the rigth request header?

Anyone has tried this?

This should work. If you need the language only (i.e. the first two letters), you might use s.th. like this:

return(substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2));

This will result in a parameter value like en or de or…

Oh, wait, does that mean to implement content negociation I only need to filter the datasource by a param ‘country’ and dynamically fill it with the rigth request header?

Exactly.

Anyone has tried this?

Not I, but it’s the same principle as any other filtering.

And do we think its ‘a good thing’ to filter language by these params, not present in the url path?
I wonder if a manual bypass/language selection should be best with a url param, so it caan be bookmarked. If not, changing/overwriting the ‘invisible’ param by clicking a link is possible?

I seldom come across sites that automatically know my language, wonder why this isnt more mainstream.

newnomad: You’re right, you should let the user decide.

URL-wise it would be the best to put the language in the front, like example.org/de/blog/whatever but I guess it will make things a bit complicated (duplicate Pages for each language).

You could also set a cookie (don’t know how to do that in Symphony) if the user decides to use a different language and filter by its value.

I have set up my website with two domains which serves content in English or Dutch depending on the domain. You do not need duplicate pages, a simple choose statement enables you to display either an English or Dutch piece of text.

You could store the HTTP_ACCEPT_LANGUAGE in a cookie and change its content when visitors decide to view the website in another language. I think it is better to give users the choice, but I hope they can find the link to the English version if they visit vrieswerk.nl.

cartsen what if…. you were catering one language to 2 countries, like here

And I have plans on 1 domain to offer versions of the site for each (non 3th world) country, and of each of that version a version in each language that google translate lists…. because in our global village-world a citizen could reside/surf in any possible country and speak any other possible language.

But I will get exponential duplicate content..the only thing different per country is prices, the textcopy is all the same.

Should a nospider xml map for the country variations be enough to avoid this?

You could use <meta http-equiv="content-language" content="nl-nl" /> and <meta http-equiv="content-language" content="nl-be" />.

For one project I use en and nl for the same domain depending on a Get parameter, and Google shows the right version in the results depending on the language/domain you use for Google. The content is actually served in English or Dutch though, which might help.

For vrieswerk, the results show vrieswerk.com first at google.com and google.nl, but vrieswerk.nl is also shown on the first page of google.nl. I hope this improves with time (and more content), but apparently Google does not understand that this is one website.

Since it would be more user friendly to offer a localized domain to different countries, I hope that Google does not see this as duplicate content. However, when the content is exactly the same I have decided to redirect .eu to .com or .nl, for this reason. When prices are different, you can not do this, so you are more or less at their mercy. I would wait on your initial search ranking before meddling with nospiders.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details