Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hi.
We are running a little site (about 100-200 nodes at ataxi.ro) in both English and Romanian on the latest version of D6 and a couple of contrib modules included i18n. I noticed that the database recently got very large. When I looked in phpmyadmin, of the 67MB database, 47.1MB was taken up by 'locales_source'. It seems a bit strange.
I attached a screenshot of some of the strings in it. It looks like it stores entire pages as strings? Is this normal?
Thanks.
-Daniel Chvatik
Adulmec
| Comment | File | Size | Author |
|---|---|---|---|
| ataxi.ro_.jpg | 239.57 KB | kerberos |
Comments
Comment #1
kerberos CreditAttribution: kerberos commentedIt's up to 64M out of 79M now. That definitely cannot be right.
-Daniel
Comment #2
keesje CreditAttribution: keesje commentedI don't believe this has anything to do with internationalization module. I do not have an answer, although I would like to know why the "locales*" tables have to grow this big (not as big as yours though..) I see this in some degree on any Drupal6 site where other languages are enabled, and thus auto importing translations when available.
One tip: do you alow user imput (dynamic strings) to be t() parsed somewhere in your code? This could explain the growth partly.
Luck,
Kees
----------
Dekbedovertek kopen
Comment #3
Jose Reyero CreditAttribution: Jose Reyero commentedActually, i18n module just stores trings in other texgroups than 'default' so this may be some other code/module using t() for not hardcoded strings.
Comment #4
greenSkin CreditAttribution: greenSkin commentedFor us this is an issue with i18n's menu translations. It keeps inserting new menu sources instead of updating.
Comment #5
greenSkin CreditAttribution: greenSkin commentedComment #6
designerbrent CreditAttribution: designerbrent commentedsubscribing
Comment #7
Jose Reyero CreditAttribution: Jose Reyero commented"It keeps inserting new menu sources instead of updating."
Still happens with latest -dev version? Steps to reproduce?
Comment #8
kerberos CreditAttribution: kerberos commentedWe'll give it a try in the next week or two and let you know if things have changed.
Thanks!
-Daniel
Comment #9
Natzrut CreditAttribution: Natzrut commentedDid you try it?
My locales_sources is now about 260MB and still growing (German/English site)...
In this thread I found an explanation for the problem:
http://drupal.org/node/359249
Greetz,
Rainer
Comment #10
Natzrut CreditAttribution: Natzrut commentedI've tested the latest dev-version of i18n and it doesn't work for me.
After the installation I had a total chaos and content of both languages was mixed. So I went back to the old version(6.x-1.2) and the database table is still growing.
Does anybody know if it's possible to only clear the table and delete all the data in it? So it could begin to grow again. That would help for now...but I'm afraid to loose translated data.....
Comment #11
Jose Reyero CreditAttribution: Jose Reyero commentedThis should be fixed by #359249: locales_source table grows on each request, #782036: Duplicates in locales_source and some other i18nstrings issues.
Comment #13
ovlaere CreditAttribution: ovlaere commentedin reply to #2 - http://drupal.org/node/529098#comment-1890690
A late reply in an old topic, but perhaps valuable to someone:
Kees, you saved the day man! I have a locales_source table that has been growing up to 290MB just a few moments ago. After reading you post, i did a sweep of the code for t() calls on dynamic data and found out someone programmed t() around a function call that returns a dynamic list of results... (no kidding!). So removing the t from around that call solved the problem i guess.
Many thx,
Kiewie