I recently joined a team that was formerly a one man show to maintain and develop a company’s PHP-mysql website.
The current localization method is, for each section of the site, there exists a file ending in _en.php and _fr.php that contains long lists of same named variables with text in the appropriate language. At the top of each content page, the user language is determined and then the appropriate ‘dictionary’ file is loaded.
I am trying to promote as an alternative is using a db table like (id, code, en, fr) and a function to lookup the correct translation in the current page.
My boss tells me that the benefits of the first approach are: having a context for each translation, and having the translations under source control
His concerns with my proposed approach are the lack of these things, and doesn’t like the idea of having two translation systems on the site.
My concerns are that, this is data in a code file, which i was taught as a bad idea. To search for a string you have to use an ide search tool, and so I don’t see how a none programmer would be comfortable editing these.
So, is his approach better? Is mine better but only marginally and not worth rocking the boat? Is the current system a disastor waiting to happen that I shouldn’t let go?
I think that for interface things (name, surname, text in buttons etc…) is more natural to use a resource file. In .NET we use .resx, in PHP, an include file is enough.
To use an archive with an include is not resource-consuming, it would be to parse a XML.
If we were talking about big texts I would put them in a db with a different code, merely because normally I would have a backoffice to modify these contents,not for performance issues.
Take in mind that Db access is consuming too, it depends on the number of users.