If you look at the original newArticle template and the revised one – you will probably see very little difference (minus the few slight layout changes I made for the inclusion of a navigation menu). All I had to do was add the {l} and {/l} tags around the text I wanted translated. How easy is that.

Hopefully this will help anyone who has to create a multilingual site (mine was Japanese, English and eventually Korean). It really isn’t that hard once you get the basics – so do your homework. If you have a hard time getting this to work or have a question about it please let me know – I’d be more then willing to help you figure it out.

The Project Manager/Translator finally had a chance to see her translation in context and hated it. Said it looked like a bad translation script was used. HEHE. She asked to have the files re-sent so she could do a better job this time. Luckily I had just finished the first admin page. Wonder if she is surprised by the size of the translation file (it is getting pretty large).

While I was just hanging out on the PHPCommunity channel today coogle came around asking about the IntSmarty project. Told him about my current problem and sent him the translation file that crashed the site. Wouldn’t ya know it – it about 5 minutes he saw where/how the translation file formating was screwed up (there were stray single quote marks and a comma where there should not have been). John reminded me that the single quotes will end the translation string so I had extra strings just hanging around messing up the parsing. So I fix it and what do you know – it works.

John also commented that it seems I found a bug in the PHP. I haven’t a clue how or where so I asked him to report it since he would know more about the actual details involved (I only know that it didn’t work and what I did before hand). I admit it – I am a CIS person not a CS. I don’t care how it works as long as it does.

Well I now have a total of 4 pages up and running. 2 are in English and Japanese, 2 in only English. Still have to code the administrative area, backend cron programs- and get a korean translation to try that out on the pages. I almost feel done.

Anyway, here is the current scenario… opened the site in English and navigated through it with no problems. Made Japanese the prefered language (In Mozilla – Edit ->Preferences. In the Navigator list go to languages and add it or move it up to the top of the list.) and reloaded. Blank white page with the status bar saying Done.

Hmm. Time to find out where the problem is with a little debugging. Put in a few echos to see what is happening. Upload and reload. Blank white page. View page source -> Nothing. Not even a openning and closing html tag. Hmm. Check the error logs to see if it says anything… Nothing. Go to the access logs to see if any information is there about what is going on… Nothing. Not even an entry to say that someone has requested a japanese page. Now that is interesting.

Got to the PHPCommunity IRC channel and ask the guys there since I’m stumped. Explain to them what is going on and what I have done. It is suggested that there may be a problem with the interaction of the PHP and the Apache since the requests aren’t even making it to the access logs. I then recalled an email I got from the hosting service that they are upgrading the version of PHP and the Zend Optimizer. So maybe I am just catching it in the middle of the upgrade…

Someone else (cnb to be exact) suggests I try rolling back the translation file. Daah – I do need to verify it isn’t the new file. So I dig out the old file and reload it. And don’t ya know it works again! So it is the translation file that is the problem. Hours of work trying to figure out the problem and it is the stupid file. Grrr.

Have downloaded a clean new translation file and sent it back out to the translator. Made sure to tell them not to mess around with the format. Never did find out exactly what the problem was.

So now I will be going back to work on the next page. Almost there. Have the templates done and ~80% of the logic. Hopefully will have the logic done soon.

(Man – this sucks not being able to talk about the specifics of the project – never mind not being able to show it. But the company does own it and it is going to be proprietary software… *sigh*)

The problem was in the smarty_lang_prefilter. The code originally has the strings being replaced in the ISO-8859-1 character set (using the utf8_decode). But my page is in the utf8 character set (so it can be more flexable). So of course there were problems with the display of 2 character sets on 1 page. Once I removed the the utf8_decode it worked perfectly.

[php]
/**
* hack starting here
*/

/** the line below is the original line of code
*$content = preg_replace(“!{$ldq}l{$rdq}$q_str{$ldq}/l{$rdq}!s”,
*utf8_decode($inst->translation [$hash]), $content);
*/

// here I am removing the utf8_decode because my page is in the utf8 character set
$content = preg_replace(“!{$ldq}l{$rdq}$q_str{$ldq}/l{$rdq}!s”,$inst->translation [$hash], $content);

/**
* end hack
*/[/php]

Sent an email to coogle (John Coogeshall – the creator of IntSmarty) telling him of my problem and my opinion of what and where the problem is. He very quickly got back to me that he would take a look. And today he sent me another email saying that he thinks there is a “problem with multibyte support” and is taking a closer look. Man I really wish I knew Smarty and how it works. Will be taking a look at it’s code when I get back to work and see if I can pinpoint the problem since coogle does have another job (Congrats by the way and I hope you enjoy your new job at Zend) that has nothing to do with me and my problems ( ). More minds working the better. Will keep you posted.

Oh and I am just about ready to load the index page and all it’s templates on to the server and start debugging that page. Want to first get it working in English. Maybe by then I will have a solution for the problem I am having with the multibyte strings. The index page is much more complex then the login screen so I am sure I will having a couple of new problems.

And one more shout out to coogle – Thank you for your help with solving this problem. I know you are very busy, so I really appreciate you taking the time to help.

return $value;
}
[/php]

cnb is an awesome programmer and guy. You should checkout out his blog to learn more about him and what he is currently doing in the world of PHP. I would also like to thank the people on the PHPCommunity IRC channel (#phpc on freenode) for helping me get this far.