Page 1 of 1

[PHP] Multi Language File or DB?

Posted: Thu Dec 01, 2016 2:29 pm
by vitinho444
Hey guys, I'm building a multi-language website.

And I haven't decided just yet what will be my approach on this subject, but I can think of two ways of doing this.

Either I do:

Code: Select all

$lang["en"]["message_id"] = "Welcome";
$lang["pt"]["message_id"] = "Bemvindo";
...
And then just call whatever string.

Or I just add a table called "Messages" or whatever that is:
ID | Message_ID | Language | Text

And then whenever I need it, i just query it out.

Now, which of this approach is better or is there anything better?

I also would like to mention that this will be a sort of CMS site, so these messages are likely to be edited/added.

Thanks

Re: [PHP] Multi Language File or DB?

Posted: Thu Dec 01, 2016 3:16 pm
by a_bertrand
Having it in DB can make it editable via web interface however you will pay some "speed" price for it. Sure you could make the PHP editable via web as well... but then that could open the door to security issues, so be careful with source code editing panels ;)

Re: [PHP] Multi Language File or DB?

Posted: Thu Dec 01, 2016 7:12 pm
by vitinho444
a_bertrand wrote:Having it in DB can make it editable via web interface however you will pay some "speed" price for it. Sure you could make the PHP editable via web as well... but then that could open the door to security issues, so be careful with source code editing panels ;)
Exactly :P Is the db matter only about speed? I was wondering if too many queries were eventually harmful for something DB-wise. Speed is not an issue, so if query amount isn't either, I guess I'll go DB.

Re: [PHP] Multi Language File or DB?

Posted: Fri Dec 02, 2016 4:22 am
by a_bertrand
Why would too many query be harmful? However think that when you develop you will need to deploy both the data in the DB and your code. For me that's actually more annoying. Maybe you would be better served with a XML or other formatted text file?

Re: [PHP] Multi Language File or DB?

Posted: Fri Dec 02, 2016 5:19 am
by Jackolantern
I would probably suggest going with making a "resources" folder or something like that and having a string resources file in which you can set up your array or whatever data structure you want to house the different language strings.

I think there are also some PHP templating engines that can handle localization (also often called "l10n", which basically just means "L, 10 letters and then N") and it is also a feature in many MVC libraries.

Re: [PHP] Multi Language File or DB?

Posted: Fri Dec 02, 2016 10:32 am
by vitinho444
a_bertrand wrote:Why would too many query be harmful? However think that when you develop you will need to deploy both the data in the DB and your code. For me that's actually more annoying. Maybe you would be better served with a XML or other formatted text file?
Well that can be a pain in the butt yes, but there is need for DB on other stuff that is mandatory, and I'm planning on creating a install script that does all the database stuff in one go.
XML or even JSON would be a nice alternative, although the editing would be hard no? Like I imagine:

Code: Select all

<language>
   <en>
      <welcome>Welcome to Our site!</welcome>
   </en>

   <pt>
     <welcome>Bemvindo </welcome> 
    </pt>
Hm, after I did this I kinda figured it out. I could load this xml/json into a proper xml/json object, then edit it out, then export it back again right?

Jackolantern wrote:I would probably suggest going with making a "resources" folder or something like that and having a string resources file in which you can set up your array or whatever data structure you want to house the different language strings.

I think there are also some PHP templating engines that can handle localization (also often called "l10n", which basically just means "L, 10 letters and then N") and it is also a feature in many MVC libraries.
I'm using CodeIgniter, but as you said it uses those "resource" files that are php... and I would have to allow the edit only inside the double quotes, and that seems like it's harder than a simple query no? :/

Re: [PHP] Multi Language File or DB?

Posted: Fri Dec 02, 2016 12:43 pm
by a_bertrand
It's not hard to modify JSON or XML. Even PHP seriialized COULD do the trick but you need to ensure no other data than what you expect goes there otherwise you would end up again having security issues.

if you do it on the DB, then be sure you have some simple mechanism to just port those support tables from your dev to your server. I do hope you run all on your PC as dev env and then upload right?

Re: [PHP] Multi Language File or DB?

Posted: Fri Dec 02, 2016 1:14 pm
by vitinho444
a_bertrand wrote:It's not hard to modify JSON or XML. Even PHP seriialized COULD do the trick but you need to ensure no other data than what you expect goes there otherwise you would end up again having security issues.

if you do it on the DB, then be sure you have some simple mechanism to just port those support tables from your dev to your server. I do hope you run all on your PC as dev env and then upload right?
Yes I'm using xampp to do everything then I will export the database as-is, and then create a script that will do the query with that export file, thus importing everything to the server when ready to install. Is this what you are asking for?

But yeah XML could do the trick, but file opening vs query weight wise who wins? I don't care about speed, let them wait! :D

Re: [PHP] Multi Language File or DB?

Posted: Fri Dec 02, 2016 2:23 pm
by a_bertrand
Well the XML you could lend to somebody to translate while DB? It's a bit more complex.

For the DB export / re-import => not a good idea. Think when you have users on your production DB, what will you do? For sure not re-import the whole ;)

Re: [PHP] Multi Language File or DB?

Posted: Fri Dec 02, 2016 10:23 pm
by vitinho444
a_bertrand wrote: For the DB export / re-import => not a good idea. Think when you have users on your production DB, what will you do? For sure not re-import the whole ;)
What you mean? The "users" table? It's just admin panel access accounts, which will be just one I think, and will be as production is.