Project information is not kept between View/Edit links

I feel the pain. Did not yet figure out how to push query string params into the menu tabs displayed.

You want stylish or hackish solution? Yeah, I don't know stylish solution but hackish might be to use theme_menu_item_link, at least at LDO, since we can't put it into module

Slept a bit on this one. Maybe we can also use a theme preprocess function for the page template. Depending on how late our function is called. Except that it might be ugly since the output is already themed for tabs there.

I'd love to get this solved on the PHP level if possible and only refrain to JS if on PHP it was not possible.

forget the last patch. the js way is a good way :D

Well i think you are right about using preprocess_page but i think it will require rewriting alot of functions, including http://api.drupal.org/api/function/menu_local_tasks/6 (I mean wrapping it into own function)...

Now that there is a Moderate page as well with the same filters (and new filters are added), it is even more important to try and keep these working. See http://localize.drupal.org/node/117

@tobiasb: your second patch seems to be a better approach to me. Some notes:

- we do need to keep all the filtering options; see the new filter cleanup functions in l10n_server which get you a sanitized $filter array from $_GET
- http://api.drupal.org/api/function/hook_theme_registry_alter/6 says theme registry altering is only called on theme registry rebuild; how is it ensured that this file is included in that case?
- good idea to keep the filtering info for the export page too

theme registry altering is only called on theme registry rebuild; how is it ensured that this file is included in that case?

Thats the reason why only the first patch works/only the Js-Way.

Heh, you can always put that PHP code into the module itself, right?

I wouldn't add filters to menus. I'd rather store the filters in $_SESSION and retrieve them on pages where I'm interested. However if a filter is still coming via $_GET I'd overwrite the session one....

How about this approach?

I would love to write a patch but before that we need to:

1. Agree this way because this will change the way filters are passed
2. Port in CVS other "filters related" bug fixes or improvements:
   • #605294: New status filter for plural
   • #599982: Filters reset after approving suggestion
   • #605402: Default value for project filter is not set when using select

And, yes, as a next step we can even imagine storing filters in user profile ($user->data). If the user choose this (!?)

@claudiu.cristea: I don't think session based storage of filters is ok, since it causes problems for workflows, when you are in translation and want to look up similar string in another window. You'll keep using different filters in the two windows. If you store the filter in session, the second window will override content in the first. That sounds like quite bas usability, doesn't it?

Well, this can be a problem but not so big as the main one.

Keeping filters across pages and even sessions is a serious improvement. On big projects (like Drupal core) translators are working more than one day. Each day or new session they have to reenter at least the project name. This is quite annoying.

Well, I've suggested a "your last 5 filters" block or something, which would let you quickly jump back to your recent filters, and we'd remember that per user.

Ok, now with all queries & moderate.