Is there someone who can help me to understand how to build my website in two languages using php? Thank you.
kinda tall order. have you looked at existing support for multi languages in CMS (wordpress, joomla, etc) or the Templating Engines (like Smarty). The basics of doing it in PHP though could be something like so (mostly swiped from OSCommerce): create a variable for lang : $lang create a path variable which includes the $lang as a directory/folder. from index.php, test for the $lang variable, if isn't set, set it to the default lang. You create sub directories like so : /siteroot/templates/ /siteroot/templates/lang1/ /siteroot/templates/lang2/ Then its time to play match up the files, if you put a specials.php into lang1, a matching file goes into lang2. Specials.php would also need to be created at /templates/ . This would contain processing logic etc, and only when there was a need for text output, it goes to the correct language file determined by the include path. So we are using the default language and the user wants to read it in the other language. The link would be domain.com/index.php?lang=ES or whatever you use to abbreviate them. Its a good idea to set a cookie so the language var doesn't have to be passed around. Just make sure its updated if they switch back to the primary lang. that's simplistic and pretty sure I skipped some steps. rough idea though. Would require the database to store text entries for both languages if a database is used.
So for every variable that i have in en I have to have it in the other language too? ex $content="text in en" $content="text in other language"
you would have it in its own file. say we had the index.php for the site index.php It would read from /templates/index.php based off of the LANG var, it would use either /templates/EN/index.php /templates/ES/index.php In both cases, the EN/index.php and the ES/index.php file would have matching variables assigned like $title = "My House"; $content = "Buncha Text About My House WITH PICTURES!"; While the ES file would be in spanish $title = "Mi Casa"; etc. Those would be called in the /templates/index.php file. Files like (header, footer would exist in both). Believe they take all the site variables and put them into english.php, espanol.php, and so on. Those are for like Meta Keywords, Site name etc. That's the way OSCommerce has it laid out. Is it best? Dunno, its probably the only method I've really seen. WP has multi lang support but I haven't fooled with it. Joomla,drupal, OSCommerce probably have it (OSC does I know). But if I was writing it from scratch thats where I would start.
Thank you for help. But when you click on en flag to see the text in en where the link will take you? Will take you every time to en/index.php. ?
nope, i just used index.php to simplify the example. that's OSCommerce's method of doing it. They have each page defined and provide files for those. While using the database to provide the language based descriptions. It works to define the site wide language (menus etc). It never takes you to anywhere but index.php at / . Those sub files would be included into the parent (calling ) document. browser reads domain.com/ it is given /index.php it reads in /template/index.php which in turn reads in either /template/EN/index.php /template/ES/index.php if the request file was account.php, it would follow the same chain. Obviously this creates lots of files and is somewhat awkward to handle. Like I said above, it wouldn't be how the content (articles, products, whatever) was handled. The flag link with English or Spanish should leave the site visitor at the exact location they were, but display the page in the other language. so if its domain.com/foo.php and they click spanish, it should come up.
FWIW, I do a lot of multilingual web sites. I tried using gettext but found it too limiting. Here's the approach I normally take: 1) URL construction like this: www.example.com/en/hello.html - it keeps things simple. 2) mod_rewrite pulls off the language part and passes it as a variable ($lang) to each page. It's passed to a singleton object that deals with language issues. 3) all images that contain text are also named "en_banner.png", "zh_banner.png", "ar_banner.png", etc. 4) template code (which is used to build each page) asks the language object to select stylesheets based on the language (since some languages require "direction: rtl;" or more spacing or whatever). It also makes the little links at the top of the page for switching languages. 5) every single text string is identified by a short tag ("welcome-message", "logged-out", etc.). When I need to output some text, the tag is passed to the abovementioned language singleton which looks it up in a hash table, does any necessary word substitution ("You last logged in on ___") and returns the final string. 6) editing translations is done by a separate program that actually writes out a PHP file containing the hash table as an associative array. This seems to provide the best runtime performance. 7) everything Unicode and UTF-8 - always. The only exceptions are for languages with bad Unicode support in client platforms, like Burmese. 8) save a cookie to remember last-used language. Used ONLY if the user comes back to / rather than a specific page inside the site (remember that all URLs within the site already contain the language in them). Advantages of this approach: 1) The individual pages don't have to be terribly aware of language issues. They need to use the right selector when getting vocabulary from the database - "where lang_id='{$l->id}'" - and handle echo a little differently - echo $l->_('logged-out') instead of echo "You have logged out." - but otherwise they can just work normally. 2) Adding more languages to a site later on is easy. I just had to add French to a complex site with over 5000 pages that was only in English and Arabic. Aside from the data entry for the translations (which I didn't do), the whole thing took me less than an hour. 3) It performs quite well. 4) Clicking on the flag icons instantly displays the same page in the selected language, rather than requiring the user to navigate back from the top and find it again. 5) No session required, and as a corrolary, when someone in France sends a link to their friend, the link stays in French. 6) Search engines understand it.