String filter form too wide

Seen this. Would love to have suggestions on how to wrap this to keep being useable. I'd expect that if we wrap, your screen would be "polluted" vertically.

When I look at such pages on Safari/Mac OS X, I notice that resizing the browser page the table has the same size, while the rest of the page gets resized (see the attached screenshot).

Yeah, the reason it does not resize is that the select boxes and buttons obviously have no way to collapse in width and the text inputs we set to a certain width to be meaningful. The project input is still not wide enough to fix many of the project names, so sometimes you still need to guess in an autocomplete to whether the project you are picking is the right one. So instead of shortening it, we'd actually need to widen. That conflicts with having small screen sizes, so obviously we need to break with the all-on-one-line mantra.

Applied to localization server in general.

why not disalbe right sidebar or move the sidebar downward

The problem is more how the filter part is build.
The fact is that the form fields in that part of the page are always inline, and don't resize. Just to make an example, the form fields used by the filter in the issues queue wrap around when the page is resized (there is the problem that the table is hidden by the right sidebar, but that is more caused by the theme used).

I'd more then welcome patches to improve the display of this form, since it came up a few times. Drupal.org's project filtering does not use a table, so it is not displaying on one line. It would be a good idea to study the markup/styling for that form and apply it here.

modify from theme_table function

Did not yet have a chance to look at the patch (note sure why does it duplicate so much code), but just marking the issue as having one needing review.

I had the same feeling that the patch is duplicating code when it is not necessary; then, l10n_community_theme_table_cell() is a theme function, but the function name is not correct.

Clean up

The patch should be formatted following the coding standards; the code that outputs HTML content should be put in a theme function.

Thanks for the reviews.
but it already a theme function ? (theme_l10n_community_filter_form)

btw, I uploaded a new patch again.

I changed the indentation of the code, and removed extra empty spaces at the end of the function.

I think the conceptual problem with this patch is that it tries to build an HTML structure off a data structure which was purposefully built for an HTML table. Since the original data structure is already built in a theme function, we can just modify that instead of adding another layer to try and work out something not a table from data built for a table.

Also, the CSS has code for this filter form, which then should be removed.

Here is a slightly tweaked version of the patch which produces this output:

I've added background color to this, since it looked odd without one, and melded too much into the pager and the translation form below it.

Patch is against 6.x-2.x but I think will apply unmodified to 1.x as well.

Committed to both branches. Thanks for your help!

Oh, and deployed to localize.drupal.org too.

Nice !!