3

They are some questions already about this on stackoverflow, but none is really clear about the 'best practice'.

For the content design, what are the options and what is the better option?

Some options I know are using folders: site.com/en/ and site.com/fr/ or redirects site.com/index.php?language=en

An even easier practice is using a new url: en.site.com and fr.site.com

But what if I want to keep site.com/index.php and nothing more ? What are my options for that?

For example, if you change the language on LinkedIn, there's nothing changing in the URL. How do they work there ?

update: in my case the website is a platform, using LAMP stack. Technical advice is also welcome (like how to store/link all the different language files)

Nicolas.
  • 453
  • 1
  • 5
  • 27

4 Answers4

5

You have some options, and each has its own advantages.

If you have a web app, which should not be indexed by search engines, then you are free to do whatever you want. You can keep a language setting in your Session and show strings in the chosen language. This will simplify URLs and management.

However, if you have a standard website which should go into Google, then your options are restricted. If you use the former approach, google will be confused and will index only one language, or, worse, make an ugly mix of the languages. Google does not keep sessions when indexing your page, so if you have two versions of the same page in two different languages, they need to have different URLs. And passing a language as a GET parameter each time is ugly, error prone, and not user friendly.

So you should either have languages as folders (eg. site.com/en/), which is the best options, or use subdomains. This can be a problem, however, because each subdomain is indexed as if it were a separate website, so things like pagerank and site reputation are split among the two.

Palantir
  • 23,820
  • 10
  • 76
  • 86
  • 2
    Exactly. Pretty much the only solution without having any SEO disadvantages is using folders, as most commonly used by large sites (as far as I can tell). – Anpan May 29 '13 at 08:15
1

Here are my recommendations based on multi-languages web sites experience

  • You can determine the language of the browser in Javascript (see this), which is a good start in having a language that likely fits the user demand

  • Use utf8 for encoding, everywhere (browser headers, programming, database). The only drawback I know of utf8 is that in some cases, the number of bytes it takes is bigger than another encoding matching more closely a given language (utf8 is opened to any). Big advantage, it covers any language, the ASCII part (bytes < 128) is the same as a western encoding (takes only one byte) ...

  • Store the user preferences (not in URL).

    • either in a cookie (+ : user does not have to be logged it on his computer to keep her prefs ; - : when user accesses the page from another computer, the cookie is not present and he/she has to reselect the pref).
    • or in a session (requires user login to deterime which user is currently using the site)

  • Regarding the site structure, if you don't store the user preferences, the common /us /fr /jp... solution has advantages: search engines robots will find all languages from root (the page display doesn't depend on user choice). Or you could load only a language dependent Javascript that displays the page immediately (after JS download) in the language of choice, without the need of a page reload / redirect.

Community
  • 1
  • 1
Déjà vu
  • 28,223
  • 6
  • 72
  • 100
1

You can tell Google what the parameters in the URL mean through Google's Webmaster Tools. So if you use a standard convention like index.php for the main page and a parameter like ?lang=fr for let's say French content in regard to SEO as long as it's a real translation. Likewise when Google.fr crawls the site you would present their users with the French version of the page based on their default setting in their browser. This will increase stickiness on the site and then increase the rank for the selected search terms in French. You can check their default language with this in PHP to make it less heavy on the user's end:

<?php

$lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2);
echo $lang;

?>

Then you would simply concatenate the language selected (as an overlay) to the end of the query string (if it's not the default), bypassing the need for storing a cookie. This should also help from a user experience standpoint. It's not as "pretty" but if people aren't typing it in, it's much more user friendly in that:

  1. People can switch languages by changing the variable
  2. People can provide a link to a user in another country and they can be presented with the page in their native language intuitively when PHP checks their language. "Do you want to see this content in French?"
  3. The native language could in theory be translated on the fly with something like the Google Translate Widget or Google Chrome's built-in functionality.
  4. Content is only served on one URI per page meaning you would not have to rewrite several redirects between versions in the event of stale content. As you're not likely translating into both languages at the same time.

From Wikipedia on Chrome:

As of February 2013, according to StatCounter, Google Chrome has a 37% worldwide usage share of web browsers making it the most widely used web browser in the world.

As for storing the files, you can make separate tables in the database for each language, enter in the content in the native language, then duplicate that content to the other language's table. Then you could translate that content live on screen if so desired, or allow someone access to your CMS who could translate the content. Both records would have the same ID in the database so the page would be served appropriately when the language was looked up.

Large corporate sites do the handling of the URLs in a couple of ways, they would show french content at http://www.some_website.fr/ and English content at http://www.some_website.com/. Sites like wikipedia use a subdns so http://fr.wikipedia.org/ and http://en.wikipedia.org.

HTML5 supports the lang='fr' approach to declaring content on screen.

AbsoluteƵERØ
  • 7,816
  • 2
  • 24
  • 35
0

I don't know what's your situation but, imho, you shouldn't use new urls.. it would only be a useless waste of resources (all kinds of resources).. If your website's client-side is javascript-based, you could use libraries like i18next, which gives you great support in localizations.. That's a valid alternative if you agree leaving the localization at you application's client-side.

For server-side localization in php, i wouldn't be of any help..

Alexxus
  • 893
  • 1
  • 11
  • 25
user2274431
  • 77
  • 2