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

You can use easiest language PHP Multi Language Class - LangQuery

You can save your language data to .ini files than just call it by

include("LangQuery.php");

$L=new LangQuery();

// Write Hello World
echo($L('hello_world'));

// Write Hello World Easier - In-line Echo Feature
// You don't have to write echo. Just add '>'
$L('>hello_world');

// Use in Strings
echo("Hello Universe. {$L('hello_world')} Hello Europe");

// Write my age with parameter
$L(">my_age",25);

// Write my name and age with parameters
$L(">my_name_age","Recep",25);

Answer 2

Take a look at these questions:

• How would you transform a preexisting web app into a multilingual one
• Design Considerations for Internationalization

And take a look at the Zend_Translate class from the Zend Framework.

Answer 3

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.

Answer 4

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 5

I am now designing a very tiny CMS that must be multilanguage.

One of the features that mosts concerns to me, is that the client can spontaneously decide to add or remove a language.

For this reason, I am not aiming the design adding suffixes to the database tables, I can not (and want not) to modify the table names or access them using dinamic names, nor adding or removing fields each time a language is defined or removed.

I would not use files either, just because I like databases and they are easy to mantain.

And lastly, I think in two types of translation:

1. The web text.
2. The content text.

Therefore, my design aims to:

• languajes A table with the languages defined.
• translations A single table that will have all the messages, as follows:
  • [pk] table_name the name of the table which content will be translated.
  • [pk] field_name the name of the field which content will be translated.
  • [pk] row_id the row identificator for the item that will be translated.
  • [pk] language the language that the text is translated.
  • text the translated text.

That means that the tables which fields will have content in a single-language scenario, now will have its content void, because it will always be in the translations table.

That will increase the sql querys complexity, but it allows me to develop tools to maintain the translations in an easy way. Also, the complexity of the sql will exist only once, just when implementing the solution. If that implementation is properly designed, the maintenance / extensibility of the site doesn't have to be a major problem.

Edit:

After some conversation with developer friends, I think that the solution i am aproaching here has too much charge on a single table.

Another approach that I will study from now on is creating an extra table for each "translatable table" as follows:

• any_translatable_table: The table which need to translate any of its fields
• any_translatable_table_translations: The table where the translations will be stored.
  • [pk] field_name the name of the field which content will be translated.
  • [pk] row_id the row identificator for the item that will be translated.
  • [pk] language the language that the text is translated.
  • text the translated text.

This scheme inherits the concepts from the first one, but separates it's content per tables. This alternative solution may increase the performance and isolate the problems (as indexes problems).

The extra translation table per "translatable table" will be created at the same time that the original one.

And about the sql querys, the complexity is still the same: The first approach needs the table name to search into translations table, but the second just adds the suffix "_translations" at the table name.