Closed (fixed)
Project:
Localization server
Version:
5.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
25 Dec 2007 at 14:56 UTC
Updated:
9 May 2008 at 18:54 UTC
Jump to comment: Most recent file
Comments
Comment #1
gábor hojtsyYes, 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).
Comment #2
meba commentedLoading 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...
Comment #3
meba commentedI 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.
Comment #4
meba commentedOne more try...
Comment #5
psicomante commented#4 is very a clean view. Great. +1
Comment #6
gábor hojtsyWell, 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.
Comment #7
meba commentedBut 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?
Comment #8
gábor hojtsyI don't have a large dataset unfortunately. pvasili has: http://drupal.org/node/200927
Comment #9
psicomante commentedI 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
Comment #10
pvasili commentedNow (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.
Comment #11
meba commentedpvasili: it would be better if you finally update to -dev version and try yourself...
Comment #12
pvasili commentedI 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.
Comment #13
gábor hojtsypvasili: 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).
Comment #14
pvasili commentedHas sent. Do not forget to clean a prefix in tables...
Comment #15
meba commentedGabor, 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.
Comment #16
gábor hojtsyWhy not use the LEFT JOIN ... ON form here, as Drupal uses all around?
Comment #17
meba commentedI just think that LEFT JOIN is slower than selecting from multiple tables, but maybe my deformation. Rerolling
Comment #18
hass commentedThis is what we need... :-)
Comment #19
hass commentedThis 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
Comment #20
meba commentedRerolling and fixed ordering by date. Applies to DRUPAL-5 CVS
Comment #21
brmassa commentedJakub,
another feature well implemented. Tested and working just fine.
regards,
massa
Comment #22
gábor hojtsyThanks, 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).
Comment #23
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.