bradgrafelman wrote:Not if you split it up according to the language. For example, you could create a directory 'lang' and it in have lang.en.php and lang.fr.php for the English and French languages, respectively. Inside those files would be the variables containing strings only for that language, and you'd simply include lang.(language chosen).php in your app.
I'm pretty sure this is how applications such as phpMyAdmin support multiple languages.
Yes, that is how most do it. Its an easy, quick way. More so if you are the programmer, the translator, the Q/A guy. But for large multifile/multilanguage projects with teams, this is not a good way to manage it.
Basically, one should use gettext facilities to get the job done. String variables/arrays/constants can take up a large chunk of PHP global space. Loading the strings, initializing, sucks up memory and CPU usage. String tables are best left on disk for lookup anyway because of their size. Loading in string tables for every PHP file with a string in it is wasteful. In addition, you want a policy/process to managing this. Too many cooks in the kitchen can set fires that add to the cost of development and create more headaches. Internationalization is a tedious, time consuming, and boring task.
Rather than go into a long winded explanation, I wrote an article PHP localization on my thoughts. Although more complicated, I think the benefits outweigh the time spent using it.