multilanguage web sites, one set of pages or multi-set of pages

searain

The database will be the same. But for the web site pages, we can have two approaches.

approach 1:

build up one set of the web pages, in every page, check the language code, and then decide to see which language contents you are going to display, also decided which language contents from database you are going to pull out.

english

http://www.myshop.com/catalog/index.php?language_code=en

german

http://www.myshop.com/catalog/index.php?language_code=de

approach 2:

build up multi-set of the web pages, each language will have a set of web pages for it (just build up one set and copy it and translate it to other sets). and grab the data for that language from the database.

english

http://www.myshop.com/english/catalog/index.php

german

http://www.myshop.com/german/catalog/index.php

I prefer the approach 2

Because in this way, all these static web pages, could be no-programmer involved. Also all these web pages, could be what you see is what you get html pages (with php code embedded only when necessary). It is easy to modify, to do the regular html programming (if we call it programming), to do the web page art design.

But if approach 1, every page is programmer involved. And you grab the contents from language packages, but the web page is not "what you see is what you get", you only see a lot of php tags there. Not easy for custom design, for static web page updated, for art design etc.

What do you think?

Thanks!

dalecosp

Well, I'm of no practical help 'cause I've never done it.

Examples from the real world: Approach one --- phpBB. It's a whole freakin' lot of PHP, and nothing is echo'ed as a raw string; all the strings are part of a big array, $lang. (Quid pro quo, they may have changed the way they do things, but that's how it was last I checked). Certainly you must be a hacker to figure out what the heck is going on.

Approach two --- FreeBSD.org. Every bit of that site is marked up in SGML, all $n languages (and there are many) and rebuilt every night by a tremendous set of sh/awk/sek/PERL scripts, HTMLTidy, docproj/jadeTex and more. So it takes masterminds to oversee the process, but most anyone can actually contribute to the documentation.

Now, to figure out whether I've actually said anything different that what you said in the first place ...

I'm not sure how I'd do it, it really depends on the nature of the project, and probably both of these examples won't have the same characteristics as your project.

Probably your decision should be based on maintainability, if that's the sort of site it is. Otherwise, I can't see how it would matter much, except it might actually be easier to take #1 if it's a solo project.

But I've been wrong before, nearly most every day. There are some geniuses here who have practical experience, I'm sure. We'll see what they have to say, I hope.

bpat1434

Well, your option 2 will take the amount of space your site uses for one language, and multiply that by x languages. For example:

You design the site in English, and it takes 2 MB (total). You have 30 languages that you port your site to. 30 * 2 = 60 MB for your site.

Now, using approach 1, it will only take a few Kilobytes for each language, and 2 MB for the rest of the site.

If you're worried about having the PHP seperated from the HTML code, use a templating system. That way, all your pages are in PHP. And your designers can create HTML pages and you can tell them something like this:
"Here are the variables (structured like: {VAR_NAME}) and here is what is required on x, y, and z pages. They design the HTML, and include the tags. Then you, or a PHP programmer, writes the backend to take the template and parse it replacing the vars with content. That's how phpBB works. They set up a template, and then leave it to the community to design skins for it. The php code is completely seperate from the HTML, and yet you never really have to "code" PHP, you just have to remember to put content placement holders where you want the content to be.

The language files would be a huge array that sets default keys, to the language translated values. So an english lang file would look like:

<?php
$lang = array(
    'welcome' => 'Welcome to my website.',
    'error' => 'We\\\'re sorry, an unknown error has occured.',
    'qerror' => 'An error occured during the query for this page.'
);
?>

Hope that helps out a bit.

~Brett

searain

Space shoule not be a big problem.

I have a gallery site, a few photo images will be larger than the web site php pages.

And I have a e-commerce site, which have 4000 items. More than half of the items have images. So the site is huge but 98% of the size goes to the images and I could reuse these images for different language packs.

Besides, I am not make a system that is going to have all the languages versions.

I am talking about built the site for the specific clients (All I need is a base system, and I will mirror copy the set and ask the clients to offer the translations.)

So for a specific client, so far 5 languages is the most I have been working with.

bpat1434

Well, you asked for opinions, and you got two rather well spoken ones. I'll shut up now and let others answer you.

~Brett