I think it's neccessary to see, who authored a suggestion. As far as I know, this information is already available in translations table, it's only a matter of displaying this information.

Comments

gábor hojtsy’s picture

Yes, sort of. We would need to load the user for each suggestion or join with the user table to get the name. There is also an issue for presenting the user name / submission date of the translation itself. Maybe we can repurpose that issue and make up something good for both: http://drupal.org/node/195028 ? (I think it is the same UI problem. We try to avoid clutter).

meba’s picture

Status: Active » Needs review
StatusFileSize
new40.37 KB
new1.13 KB

Loading an user for each suggestion seems OK because it's just one suggestion per time...Joining the table would be pain I think.

And also, I think that issue is something different.

I am rolling a patch and screenshot, to move a little bit...

meba’s picture

I am trying to work out, how to separate a suggestion from author information which is a little bit joined now...We wouldn't need to confuse user that this translation is different that it seems.

meba’s picture

StatusFileSize
new1.17 KB
new27.95 KB

One more try...

psicomante’s picture

#4 is very a clean view. Great. +1

gábor hojtsy’s picture

Well, joining to the user table might still be a less expensive operation then loading users. It depends on how many extensions do you have on your users. If you have buddy lists or whatever else, all these modules load external data on your user (ie. they execute more and more queries per user). Doing that for all suggestions might be expensive.

meba’s picture

But it depends on how many strings do you have in user and translations table which will be really huge on Drupal.org. If you have a large user/translation base to try, I can provide a different patch to try, do you?

gábor hojtsy’s picture

I don't have a large dataset unfortunately. pvasili has: http://drupal.org/node/200927

psicomante’s picture

I can try the patch but we have a less large dataset unfortunately.

* 222 projects managed
* 2901 files scanned
* 22227 strings to translate
* 6321 translations recorded
* 228 suggestions awaiting approval

l10n_community_file 2,901
l10n_community_line 118,345
l10n_community_project 222
l10n_community_release 278
l10n_community_string 22,227
l10n_community_translation 7,660

pvasili’s picture

Now (all modules with drupal.org > 5.3):
* 1400 projects managed
* 11918 files scanned
* 58993 strings to translate
* 22854 translations recorded
* 4881 suggestions awaiting approval

table(record/size)
l10n_community_error (3,528/866.0) КБ
l10n_community_file (11,918/1.3 Mb)
l10n_community_line (1,278,106/61.9 МБ)
l10n_community_project (1,400/93.0 КБ)
l10n_community_release (3,355/327.6 КБ)
l10n_community_string (58,993/4.3 МБ)
l10n_community_translation (29,360/4.6 МБ)
10n_groups_group (6, 2.1 КБ)
(2 Gábor Hojtsy) - I can send to you a copy of these tables :). If it will help to solve a problem.

meba’s picture

pvasili: it would be better if you finally update to -dev version and try yourself...

pvasili’s picture

I use version alpha1 (http://drupal.org/node/202651). I shall try to make it in new year :).
Happy New Year you and ALL.

Thanks Gábor Hojtsy for its work and the good project.

gábor hojtsy’s picture

pvasili: I would be happy getting a package with your database for bigger performance testing and improvements. I just sent a contact mail to you (because it is unrelated here).

pvasili’s picture

Has sent. Do not forget to clean a prefix in tables...

meba’s picture

StatusFileSize
new1.74 KB

Gabor, I think you are right and we needn't to measure this. I thought that the SQL was more complicated. Attaching a patch, doing the same as before, but using direct SQL. There is no need to make a slower JOIN, because uid_entered is always at least 0 = Anonymous.

gábor hojtsy’s picture

Status: Needs review » Needs work

Why not use the LEFT JOIN ... ON form here, as Drupal uses all around?

meba’s picture

Status: Needs work » Needs review
StatusFileSize
new1.75 KB

I just think that LEFT JOIN is slower than selecting from multiple tables, but maybe my deformation. Rerolling

hass’s picture

This is what we need... :-)

hass’s picture

This patch is very helpful! kkaefer have installed it in the DE site... i found one bug with the order. We should order the suggestions by date... today - it get mixed. I haven't reviewed why.

Wrong order with patch:
by User1 at 11. February 2008 - 7:15
by User2 at 11. February 2008 - 23:34
by User3 at 11. February 2008 - 11:28

Should be:
by User1 at 11. February 2008 - 7:15
by User3 at 11. February 2008 - 11:28
by User2 at 11. February 2008 - 23:34

meba’s picture

StatusFileSize
new1.82 KB

Rerolling and fixed ordering by date. Applies to DRUPAL-5 CVS

brmassa’s picture

Status: Needs review » Reviewed & tested by the community

Jakub,

another feature well implemented. Tested and working just fine.

regards,

massa

gábor hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Thanks, committed with a slightly shortened query (ie. I removed the "AS" keywords, which are not much used in Drupal and one pair of parenthesis in the ON clause).

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.