[RESOLVED] Language management, an encoding problem

void_function

I need to supply different translations of website content. For website elements, I thought it would be fastest to keep a PHP file with associative array like:

$lang['login']= 'Login';
$lang['logout']= 'Log Out';
$lang['home']= 'Home';

etc...

Then, tracking the &lang= variable in URL I can dynamically load language arrays. For english (&lang=en) I would load en.lang.php. For french fr.lang.php, etc... Then, for proper page elements I'd echo appropriate $lang[] elements which contain language as loaded according to &lang= var passed in URL, with english as default.

My problem is this:

Either I need to supply charset string with each language PHP, the string that will be echoed in http-equiv meta tag, or I use global utf-8.

If I use charsets, I cannot solve for situations where more than one language is shown up on a page (for instance in forums, if users use their own characters for whatever reason, these will be improperly encoded).

If I use utf-8, I solve for multiple languages on a page, but I don't know how to encode the PHP files. The problem is, each of translators will run (most likely) Windows with their local codepages, and txt files that I would supply them with for translation do not contain multibyte characters. I don't know if Word, Winword or Notepad can save in utf-8, as I will require them to save plaintext files that I'll check and save as .lang.php files.

One solution that I see is having every string for translation stored in temporary database table, have the translators use the web interface (utf-8 encoded), and have the ability to export a PHP file from such a database.

Can anyone give me an advice, or their own experience? Thanks.

greenie2600

Why not just provide the translators with suitable tools?

Another thought - it might be a little easier to use multidimensional arrays:

$lang["en"]["hello"] = "Hello!";
$lang["es"]["hello"] = "&iexcl;Hola!";
$lang["fr"]["hello"] = "Bonjour!";

MarkR

Just ensure that all the translators use software which can work in UTF-8. To make things easier for them, put a (fixed) comment at the top of the file which only reads correctly in UTF8.

You may want to put some kind of special string in to ensure that the file is definitely UTF8. Check this at runtime so you can have it "fail fast" if someone accidentally saves the file in some other encoding.

Mark

void_function

Thanks for your answers, guys.

Well, UTF-8 is totally new to me, so I didn't know (I just realized) that even Notepad, or EditPad that I like to use, can save into utf-8 (there is an option in SaveAs dialogue for Notepad), I always thought it had something to do with automatic internal encoding if you choose appropriate font, which never worked, of course.

However, I can't use the file as PHP then, since start of the string (before '$') gets special codes. Or is there a way to force PHP to work with multibyte encoded scripts?

Sorry if I sound stupid, UTF-8 is really terra incognita to me.

void_function

greenie2600 wrote:
Why not just provide the translators with suitable tools?

I never needed them so I don't know which to use. Can you recomment any?

Another thought - it might be a little easier to use multidimensional arrays:

Actually, it won't. It would result with gigantic file even for five languages. Having them separate is much better for handling, besides I'm optimization freak and my codes are as small and fast as I can squeeze out of them. 😃

MarkR

void_function wrote:
However, I can't use the file as PHP then, since start of the string (before '$') gets special codes. Or is there a way to force PHP to work with multibyte encoded scripts?

Probably what you're seeing is a byte-order mark (BOM). This is a sequence at the beginning of a file which indicates that it's in UTF-8 (and indicates its endianness).

Normally these are ignored by most tools, however, PHP will just pass it through like any other HTML, possibly resulting in unintended output.

The BOM is technically a zero-width space so it doesn't appear as a real character in the editor.

However, it may break PHP by causing it to output headers before you're ready (especially if output buffering is off).

One option would be to enable output buffering- which will certainly illeviate this problem.

An option which I use is to put localisations in .ini files and load them with parse_ini_file. In these, a BOM will definitely be ignored.

Mark

void_function

MarkR wrote:
An option which I use is to put localisations in .ini files and load them with parse_ini_file. In these, a BOM will definitely be ignored.

!!!

Thanks, that solved the problem. Produced no errors nor warnings.