Pa, konceptualno, ima vise pristupa u zavisnosti od tipa visejezicne podrske koji zelis da implementiras. Za staticke elemente na strani (user-interface, itd.) dovoljno je da koristis niz za svaki od podrzanih jezika a informacije o izabranom jeziku drzis u cookie-ju.
Primera radi, za meni mozes ovako implementirati podrsku:
Code:
<?php echo '
<ul>
<li>' . $lang['home'] . '</li>
<li>' . $lang['contact'] . '</li>
<li>' . $lang['portfolio'] . '</li>
</ul>';
Pritom imaces zaseban .php fajl za svaki jezik koji ces include()-ovati zavisno od izbora korisnika ili informacije u kukiju. Primer fajla za srpski jezik bi mogao biti:
Code:
$lang = array(
'home' => 'Osnovna strana',
'contact' => 'Kontakt',
'portfolio' => 'Portfolio'
);
Na taj nacin elegantno resavas staticke elemente i bez problema dodajes nove jezike as you go...Razmisli i o koriscenju $_SERVER['HTTP_ACCEPT_LANGUAGE'] da eventuano "ponudis" korisniku non-english jezik pri dolasku na stranu, ili nekih Ip2Country skripti...
E, sad, za dinamicke sadrzaje, article/news/CMS bazirane mora neka bazica da se uplete u celu pricu...To je u principu never ending story po pitanju normalizacije takve baze i sporosti, i verovatno svako ima svoj trip kako bi to trebalo odraditi. Moja ideja je recimo ovakva:
Napravi osnovnu tabelu za, ajde da kazemo, article (samo osnovni primer)...
table article
--------------
id
publish_date
author
I za sadrzaje articala (jezike) koje podrzavas napravi dodatnu tabelu
table article_data
------------------
article_id
lang
title
article_body
Na taj nacin spajas osnovnu tabelu (article) u kojoj smestas sve parametre o articlima koji su language independant (broj citanja, datumi, autor, blabla) sa tabelom u kojoj su konkretni language-based podaci (naslov, telo, keywords, etc..)
Jeff, one day you’ll understand that it’s harder to be kind than clever.