What I did is register the language of the user account or selection with $_SESSION and then load strings from an ini file. PHP has good ini file support and you can read the section(s) that apply to the current page to be displayed. Using an ini file versus a database table makes it much easier to add additional languages (change the file name) and translate it with no special tools needed other than some text editor. Use numerical keys for the strings, that way you can pull the whole file through a spell checker and have it only stop at the [] sections. If you craft the ini file name so that you have the standard language moniker (such as en_us, ge_de, etc.) combined with the native name of the language (can't expect that everyone knows the name of their language in English or such), you can read in all the ini file names first and then generate a drop-down list dynamically based on the files available. If you have user accounts in your app you may want to store the language for that account in the database so that a user doesn't need to reselect each time. And you want to add code that makes a default to work.
You then need to replace all strings in the scripts with the variable name for the string. Or even better, create a function that returns the string from the ini file or if none is found return a hard coded default. That way you have at least something show up rather than nothing, even when it is not the right language or a bit outdated.
Also, if you add help functionality, you can base the help calls on the language preference stored in $_SESSION. You can also do more things, such as formatting dates and numbers based on the localized language setting. You can store the formatting in the ini file as well.
You like this? OK, 5$ please.