Multilingual Sites.
- Thread starter SpicyDuck
- Start date
Associate
Well forgetting about the Japanese site for the moment coz thats hard 
The rest shoujld be fairly easy.
Take phpBB for example. All the language information is stored in another file and adding another language is as simple as adding a different language to the same directory
I've never worked with anything else apart from PHP and MySQL so I can't really say which would be best. PHP is the most 'user-friendly' language though.
The rest shoujld be fairly easy.Take phpBB for example. All the language information is stored in another file and adding another language is as simple as adding a different language to the same directory
I've never worked with anything else apart from PHP and MySQL so I can't really say which would be best. PHP is the most 'user-friendly' language though.
Soldato
As above. A single base language file, and additional language files on top of that.
The base file contains an array of language strings, and their relevant text:
Alternative languages override these where necessary - if you don't have a translation for the message, then it falls back to the base English string.
I then use Smarty templating and assign the $lang array to the template (switching via a user preferences system), and insert the message where needed e.g.:
(You could do it without a templating engne, but it makes life so much easier for this sort of thing)
This may not be the most appropriate method when you need alternative versions of large articles, and you might be best storing the translations in a DB and pulling out the relevant one when necessary.
Switching character set should be as simple as changing the header('Content-type:...'); sent, and optionally the <meta> content-type tag. I've not used Japanese characters on a site before, only a little bit of Chinese, but are the characters you need not within the UTF-8 character set? I believe Kanji is supported, and certainly the common Chinese characters. If so, you can use UTF-8 for all languages and not worry about switching the content-type header.
There may be better overall methods, this is the one that seems most efficient for my needs at the moment - only 1 template file for all translations of a page. I'm currently working on a framework for multi-language sites, and it's the first time I've done it properly, so I'll be interested in other viewpoints.
The base file contains an array of language strings, and their relevant text:
Code:
// Base
$lang['welcome_message'] = 'Welcome to foobar.com';
$lang['error'] = 'We are having technical problems';
Code:
// French
$lang['welcome_message'] = 'Bienvenue à foobar.com';I then use Smarty templating and assign the $lang array to the template (switching via a user preferences system), and insert the message where needed e.g.:
Code:
<h2>{$lang.welcome_message}</h2>
<p>{$lang.error}</p>This may not be the most appropriate method when you need alternative versions of large articles, and you might be best storing the translations in a DB and pulling out the relevant one when necessary.
Switching character set should be as simple as changing the header('Content-type:...'); sent, and optionally the <meta> content-type tag. I've not used Japanese characters on a site before, only a little bit of Chinese, but are the characters you need not within the UTF-8 character set? I believe Kanji is supported, and certainly the common Chinese characters. If so, you can use UTF-8 for all languages and not worry about switching the content-type header.
There may be better overall methods, this is the one that seems most efficient for my needs at the moment - only 1 template file for all translations of a page. I'm currently working on a framework for multi-language sites, and it's the first time I've done it properly, so I'll be interested in other viewpoints.
Soldato
Hmmm this is interesting we are about to try to get several of our SOA based products internationalised. How do you go about finding the locale of the client?
We are about to make our pruduct switch to a right to left language (arabic) on demand which could be interesting
HT
EDIT: the scripts supported by unicode 4.1 are available here: http://www.unicode.org/standard/supported.html
We are about to make our pruduct switch to a right to left language (arabic) on demand which could be interesting
HT
EDIT: the scripts supported by unicode 4.1 are available here: http://www.unicode.org/standard/supported.html
Associate
Well I have no clue at all about how to reverse the page but I know about the locale.
When the browser requests a page it send the locale of it I think.
Using this pre-built variable ($_SERVER['HTTP_ACCEPT_LANGUAGE']) you can detect the language of the browser.
An english browser would have en-gb
Hope that helped
When the browser requests a page it send the locale of it I think.
Using this pre-built variable ($_SERVER['HTTP_ACCEPT_LANGUAGE']) you can detect the language of the browser.
An english browser would have en-gb
Hope that helped
Soldato
That's not the most stable of methods to discover the right locale for a user, and makes a lot of assumptions. Most British Firefox users, for example, will be running an en-us locale (it's the default download, and the en-gb is typically delayed until after the latest en-us release). That particular example isn't going to give much cause for concern here, but take an example such as a native English speaker in Japan using a browser set to a Korean localeNightmareXX said:
. The only real way to 'detect' locale in my opinion, is to serve a default and only switch language and content after explicit user input. Save it as a user preference [cookie/sess/profile] and it will only be a one-time issue for the user.
http://www.w3.org/International/questions/qa-accept-lang-locales
As for text direction, you can use the dir attribute in your markup, or as a property in your CSS.
Thanks a lot for all the information guys, much appreciated! .
I think what I will do, is have a database for each language, which will be switched at the database selection part of the site, via a variable which will also change the stylesheet to match.
The only problem I can see with this, is MySQL's ability (or lack of) to store Japanese script. I've just entered some into my current blog site via MySQL and it is stored as a random bunch of numbers, although it displays fine on the page.
But when I come back to edit this text, it is never reverted back to Japanese script. It stays in the database as a random bunch of numbers.
Hmm.
Phil.
.I think what I will do, is have a database for each language, which will be switched at the database selection part of the site, via a variable which will also change the stylesheet to match.
The only problem I can see with this, is MySQL's ability (or lack of) to store Japanese script. I've just entered some into my current blog site via MySQL and it is stored as a random bunch of numbers, although it displays fine on the page.
But when I come back to edit this text, it is never reverted back to Japanese script. It stays in the database as a random bunch of numbers.
Hmm.
Phil.
Soldato
is your blogging software UTF-8 aware?
getting full extended character support is always tricky
I think kanji is only in the latest version of UTF 8 it a pita to handle. arabic 's also a real pain (my current bugbare). I find the bigest problem is not just getting the srings to read rt to left across the screen but getting the user interface to change to mattch. main tab pages onm the right, application window min/max/close buttons to the top left and doing lots of move,ent of radio buttons ets across the form.
The key is to think about it at initial design phase
HT
getting full extended character support is always tricky
I think kanji is only in the latest version of UTF 8 it a pita to handle. arabic 's also a real pain (my current bugbare). I find the bigest problem is not just getting the srings to read rt to left across the screen but getting the user interface to change to mattch. main tab pages onm the right, application window min/max/close buttons to the top left and doing lots of move,ent of radio buttons ets across the form.
The key is to think about it at initial design phase
HT