Phreesoft Support Forum

I just upgraded to R34RC1 and stomped on a modified language file (I had a backup of course). A quick search of all the language files installed on my configuration showed over 40. My feature request is to dump all the define constants hardcoded in the language files and put them into a database table called language. I've done this for several websites in the past and it makes life much easier to do modifications:

• No time spent searching for text in a language.php file
• No file overlays
• New releases just update the table column of the text needing updating
• New languages are added by adding a new column
• Side-by-side translation e.g., en_us is the left column, translator enters text in right hand column

I use CS-Cart and they has a nice language table search feature in the admin section to locate and modify text. They even have the ability to add new defines all from the admin web interface.

_________________
Larry

I like the idea...

I have also used systems where you use http://www.poedit.net/ to edit your language files it also worked good.

_________________
Alvin

There are custom hooks to avoid overriding the core language files. If you define the constant first in /modules/phreedom/custom/language/en_us/language.php it will be set before the core language is loaded and will not be trampled on when upgrading.

I will be re-working the language methodology for the next release. OpenCart uses a method called vqmod which I really like as you can modify the code in the core modules as well as language defines, et al. The db idea is also a good one. I'll take a look and see what makes sense within the framework I use.

Dave

Thanks for the overlay protected directory location. I just created a language.php file with my mods and it works just fine. Thank You.

I took a look at vqmod. It looks interesting. A couple of years ago I wrote a couple of mods for a forum called Simple Machines. It was all done in xml using the search and replace methodology. I think vqmod would be good for applying patches on the fly. This way "line-by-line" mod instructions to end users go away and so does the need to distribute patched core files before releases.

I still think placing the language constants in a table would work better. I have a site where all my phrases are stored in a table and dumped into an array when I init, but I go one step further by using APC to stored the array in cache. Even without APC, MySQL does use its query cache, so repeated hits to load the array from the table just come from cache. The array could also be stored in a session var to eliminate reloads.

_________________
Larry

Larry, how about having the option to go either way?

My current hosting provider limits the amount of lag on the server by limiting the number of tables in the system to under 1000. Adding more tables would not be a good solution for me.

However, I think that having language defines on a per-language basis would be good, and perhaps parsing the language files through temporary tables might be a good option, allowing replacement terms in a way that's similar to Joomla CMS and a few other systems out there. Parsing the files as they're installed would also help reduce the occurrence of duplicates, as the system could alphabetize the entries and make sure that two different entries with the same input didn't change the output ("stomp on the output").

Just an idea which might be a little unique, as Joomla doesn't actually parse the files, and so there are still a bajillion files for each language, extension, and part of the site. Not sure how it would pan out.

EDIT: Oh, and, I implied it but I didn't write it: the system would write the output of the file after parsing it--slightly risky, but handleable.

Placing the language define files into the database only takes 1 table. The different languages are just another column in the table. To avoid duplicates, just key the column.

_________________
Larry

I'm leaning towards the cache approach. Also with the new release using an array of MUCH REDUCED language translations. My new architecture will also allow for easier customization for the language files as well as table structures, organization and better standardization of input/output processes. It all will be part of the next release later this year.

Dave