Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
If I were you, I wouldn't use ini's. Parsing them is slower compared to regular PHP variables. And they aren't very flexible; no escaping, value type constrained to numbers and simple strings, can't use other variables in your language string, etc. I use a regular php file for language strings, all packed nicely within a $lang[] array.
However, I've begun to become pathologically opposed to includes that do anything besides make class/constant definitions (which means they should always be called include_once()). So... it'd look like...
Edit - Actually, I can't do that. All my crappy text editors either can't display Chinese characters (actually font-mixing) or attach a BOM... and you all know about those strange headers already sent errors in Unicode mode.
Last edited by Ambush Commander on Sun Nov 27, 2005 4:43 pm, edited 1 time in total.
Ambush Commander wrote:Hmm... that wouldn't be too difficult to do.
However, I've begun to become pathologically opposed to includes that do anything besides make class/constant definitions (which means they should always be called include_once()). So... it'd look like...
Well, actually, I just screw OO here, and make $lang a global variable. I know it's ugly, but I'm too lazy to do it that way. But, you're right, you could just as well do it that way. One suggestion: treat the vars in LanguageStrings_XX as private and use a function to access them instead. Truly OO.
I was editing my response and missed your reply. Just to requote my edit..
Actually, I can't do that. All my crappy text editors either can't display Chinese characters (actually a font-mixing problem) or attach a BOM... and you all know about those strange headers already sent errors in Unicode mode.
Well, actually, I just screw OO here, and make $lang a global variable. I know it's ugly, but I'm too lazy to do it that way. But, you're right, you could just as well do it that way. One suggestion: treat the vars in LanguageStrings_XX as private and use a function to access them instead. Truly OO.
Haha. Well, since internationalization should be a View problem, it shouldn't be too hard to do that... You're right about the function thing... but the whole script that runs the site was originally a quick PHP hack to get the same header/footer on multiple pages: I didn't expect there to be a need for internationalization. (actually I should have...) Anyway, I'll OOPize it before it's too late.