PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!
I would like to know your suggestions and theoretical solutions about creating multi-language support in sites based on PHP/MySQL.
It's clear that separating web root for each language is bad solution.
Does anybody know a better, more scalable, and simplier solution? Just theoretically?
Method I use for now:
1) Make a special language include with array, containing all sentences in site for each language:
//eng.php
DEFINE('_TXTEN',"This is some Text");
//esp.php
DEFINE('_TXTESP',"Esto es un texto");
// index.php
if ($lang=="eng") // use session, cookies, or $_GET
get eng.php
else
get esp.php
end if
Instead of using constants you could try storing information in a database. Depending on the scale of the translation you could potentially, once loaded store that information in a session for fast access the next time.
CoderGoblin wrote:Instead of using constants you could try storing information in a database. Depending on the scale of the translation you could potentially, once loaded store that information in a session for fast access the next time.
I would stick to files. What if you have problems with your db. In what language will you show error message?
jmut wrote:I would stick to files. What if you have problems with your db. In what language will you show error message?
Same could be said of files with data corruption . For most sites I have dealt with, the database going down for any reason is a major problem which would need redirection to a "website is undergoing essential maintenance.. We apologize for any inconvenience" page in whatever language, which normally would have to be file based...
We have several different systems already in place using both database and file based translations. The database based translation systems tend to be more flexible having facilities where administrators can update translations on the fly on a page and see the result directly, automatically track translation changes, when and who etc.
I think Codergoblin was referring partly to the idea that a failing database is going to close the application anyway. What good are files if the application isn't working to start with?
The database can add flexibility, and you can still cache translations to files if it helps performance (usual benchmarking of filesystem vs database justifying that of course).
Maugrim_The_Reaper wrote:I think Codergoblin was referring partly to the idea that a failing database is going to close the application anyway.
Yeah I know... but he also meant to what I replied to
Maugrim_The_Reaper wrote:The database can add flexibility, and you can still cache translations to files if it helps performance (usual benchmarking of filesystem vs database justifying that of course).
I just want to make sure... You believe that the ultimate solution is to store the data in a database, but deliver it to the output from files which will be updated once in a while with the data in the database, so we gain the performance of the filesystem while not losing the flexibility that we can get with database implementation. Is that what you mean?
Oren wrote:
Yeah I know... but he also meant to what I replied to
I admit the DB is more likely to go down than a filesystem, although DB access should be nearly as stable in a production system so the argument what if the DB goes down is a bit of a non-argument for or against... If your database is not stable, in all likelyhood your whole web site is in trouble.
Oren wrote:
I just want to make sure... You believe that the ultimate solution is to store the data in a database, but deliver it to the output from files which will be updated once in a while with the data in the database, so we gain the performance of the filesystem while not losing the flexibility that we can get with database implementation. Is that what you mean?
The technique I supplied was as an option to those already listed. I do not claim it is the ultimate solution. As such a possible solution is to get "translations" from the database when a user first loads a page or accesses a "translation category". The information could be stored either in a users session or cached in some other way to be determined during design and benchmark tests. As I also previously stated we have both file based and database translations working and both are equally valid depending on the situation and the requirements.
I would start by encapsulating this into a set of objects, that way you can change the storage later and not change all of your code. Also you can use an interface or abstract class and implement one class for each language.
// This gets pulled from a config, database, or user prefs or something
$selectedLanguage = Language::TYPE_ENGLISH ;
$language = Language::factory($selectedLanguage) ;
echo $language->get('login-required') ;
echo $language->getType() ; // Would echo 'English'
Now your language objects can pull from a database, files, xml, babblefish or anything else and you can change it depending on your mood or the alignment of the planets.