How to make a Multilanguage website [closed]

Question

Can any body tell me how to make a dynamic multilanguage website in PHP and MySQL? I have no idea about it. I searched on Google and didn't find any good solutions.

Can any one provide me with a step by step guide? If possible make a demo for a multilanguage website. Or please refer me to any link where it explains the details about it.

Answer 1

Short answer: there is no short answer, as there are a lot of variables to consider, and plenty of work to do. So...

Long answer: I'm going to break it down as well as I can, but there isn't a "good for all" answer to a question as broad as yours.

First, variables of the task at hand:

1. List of languages: will your site be in a predefined set of languages, or will it be varied/heterogeneous? For example, a site may be entirely bilingual in two well defined languages (or, to put another example, I run an English/Catalan/Spanish site); or different sections could be available on different sets of languages (for an example, look at MS's sites: they are mostly homogeneous, but stuff like blogs, KB articles, and some docs are just available in a subset of the supposedly supported languages).

2. Translations source: is content provided in each relevant language by you or some collaborator? Or are some versions run through translation software from a single "base" language? The first approach takes a lot of extra work to produce the contents, but yields higher quality results than the second.

3. Languages themselves: once you have 1) and 2) answered, you will need to be aware of exactly which languages are you working with. Note that in the case you include dialects (ex: US English + UK English, or Argentina Spanish + Spain Spanish), you may encounter some "duplicate content" issues with search engines, but details on that are too off-topic here (just mentioning so you are aware of the potential issues).

4. Are you targeting languages in the abstract (for example, my site offers the three languages without caring at all where the visitor is: that's what I have, so choose what you prefer); or rather targeting different regions/countries? In the later case, things can get extra complex, as you may need to care about other stuff besides languages (like timezones, currencies, or date-time format conventions, to name some), but you get the benefit of being able to use country-specific TLDs.

Once you have the above well-defined, let's start working. These are the most prominent tasks you'd need to do handle:

1. Language detection: the most reasonable approach is to use a GET parameter (something like ?lang=en-us on the URL). Also, you might use some cookie and/or IP geolocation to fall back when a URL with no language argument is requested. Also, if you have the means, consider the topic of URL beautification (what looks better: example.com/index.php?lang=en-us or example.com/en-us/home?). Personally, I love the power ModRewrite grants to my .htaccess file, but that'll only work on Apache-powered servers.

2. Content management: regardless of whether you are fetching content from a DB (like article content), include files (typical for breadcrumbs, menus, site-wide headings, etc), or any other means, you will need some way to separate each version (language) of the content. Here are some examples of how it can be done:

   • For DB content, my best advise is to come up with some solid field naming pattern and stick to it. For example, I append _en, _es, or _ca to all language-dependent fields of my DB. This way, I can access the right content with expressions like $row["title_$lang"].
   • For include files, again a file naming convention is the sanest approach. In my case, I have file names ending with .en.php, .ca.htm, etc. My include calls then look like include("some-filename.$lang.php).
   • From time to time, you will be spitting out small chunks of text directly from your PHP code (for example, when labeling the headings of a table). You can use an include file per language defining a "chunks" array with the same keys, or a DB table like Geert suggested. The former approach takes less work to develop, the latter should take less work to maintain (especially if you aren't working alone).

3. Language pick: quite essential, you should provide your users a way to choose their own language, other than tweaking the GET arguments on the URL itself. For few languages, "flags" often work great, since they can be understood even if the page has initially fallen back to a language the user doesn't know at all. For more languages, a dropdown menu seems more efficient (in terms of viewport space), but you should make sure to add some visual (ie: non-textual) hints. Some sites force you to pick a language upon entering, and only have links to the home-page on each language. Personally, I have my three flags standing out on top of my site's menu, each pointing to the current address with only the language argument changed. A code like this can work quite well:

---

function translatedURI($new_lang) {     return str_replace("lang=$lang", "lang=$new_lang", "http://" . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"]; } 

---

4. CMS tweaking: if your site (or part of it) is using some kind of CMS, discussion board, etc, things can get quite messy. Speaking from my own experience, I have a phpBB forum on my site split in three main categories (one per language), in such a way that they look like three independent forums (but users just need to login/register on one of them to gain access to all languages, since they are indeed just categories of the same board). The tweaks I had to make for this to work smoothly threatened the last remnants of sanity I still keep :S. For these cases, I advise looking up the docs and support features of the specific software you are using.

Well, that's everything I can come out with for now. I think you should have enough to pull up your sleeves and get to work. Then, if you hit some wall on your path, come back with specific questions and I'm confident you'll get more specific answers.

Hope this helps.

Answer 2

The solution I always use is to create a database table, with all possible messages. For each message I use a code (abbreviation) to look it up. So for example:

lang  id        message en    login     Login en    lostpass  Lost your password? de    login     Anmelden de    lostpass  Paswort vergessen? nl    login     Aanmelden nl    lostpass  Wachtwoord vergeten? 

etc. Looking up the translations is usually fast enough by using a MySQL query, but you can also place all messages in a array and load it into memory when your script loads. Users should always be able to set the language they prefer, don't rely blindly on the language header set by the web browser.