Allow search for user

Hm, it is in the database. Look for user_approved in the translation table. Otherwise I am not entirely sure this would be a common need on the main translation interface. What do you think?

Yeah, displaying usernames (and times) for suggestions pretty much solves this problem right? Also much easier to code. We already have a CNR patch for this: http://drupal.org/node/203809

All right. This still does not generate me more time to code this patch, so I put it on my todo list. Ideas on a good user interface for this would be great. I'd expect people to "search for strings suggested by $username" and "strings translated by $username" and "strings translated or suggested by $username" and "strings approved by $username" (if I did not miss anything :). How to encapsulate this into an easy to understand interface and where to put that interface?

I suggest we rename this to "Advanced search form" and mark few more issues as duplicates. Then a discussion how this advanced form should look like would be great.

A user imported Turkish into our German translation server as suggestion for German... we need to search for users feature... and blind DROP specific user translations... *PLEASE*

I'm not sure if kkaefer have installed OG... i don't think so. There is the normal import tab... and then you are able to select every pot file you have and submit this file in every translation. There is no translation verification check build-in, yet. Would be a good idea to add such a language check feature... however it could be circumvented if the language file is not compliant and do not specify the language themself or is named differently, but it could possibly stop some users from importing wrong translation files.

kkaefer removed all the suggestions of this user on DB level for now, but it's a real life issue. I can only approve translations there, but have no shell access or direct DB access on his box.

If we don't have some more administrative features here we need to ask d.o. Infrastructure very often to fix such issues for future in a reasonable time...

No, OG is no solution here.

How should OG ever prevent against users that are members of German translation group and importing a Turkish translation file? Or do you think German people cannot download a Turkish translation file somewhere and import this into a German translation? This is a human fault... or someone trying to harm your translation.

I think this is a feature request?

So just to summarize, we have a UI problem and a performance/SQL problems here:

I'd expect people to "search for strings suggested by $username" and "strings translated by $username" and "strings translated or suggested by $username" and "strings approved by $username" (if I did not miss anything :). How to encapsulate this into an easy to understand interface and where to put that interface?

And the other issue is performance/SQL building. We currently only filter on the translations themselves. So we have "has suggestions" cached on the translation itself in the DB. If we'd need to look for all child suggestions of the strings then that would be a sub-query for the user. It would also allow us to do a subquery for string matching (currently when you fill in "contains", it does not look at any of the actual suggestions, only the main english string and the one active translation). That could however slow down the code pretty badly. But that is an assumption, not proven by benchmarks. So it can be experimented with for sure.

So we can easily search for "active translations approved by $username" and "active translations submitted by $username", but not any of the suggestions without a subquery.

#570648: Add mass moderations screen for suggestions (+ user filtering) was committed and deployed on localize.drupal.org, so now user filtering is on translations and suggestions. Yay! http://localize.drupal.org/node/117