Improve translation string search and editing interface
Zen - March 8, 2006 - 08:17
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | locale.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
The search strings page should either use sessions or GET to retain search queries across pages. Currently, there's no way to return to the results page after an operation (delete, edit..) has been performed.
-K
#1
Maybe it should be re-implemented like user_search?
#2
Yep.. something like: search/en/translated/request+new+password
The current setup actually scans $_REQUEST as opposed to just $_POST. So I believe that something like this was possibly already intended..
-K
#3
I doubt it was intended, the locale search code is quite ancient. It would be great to replace it.
#4
+1 for this... it's really tedious to keep typing in the search string again and again.
#5
Changing title. The brainstorming here (http://groups.drupal.org/node/3916) resulted in some ideas about what should we do. The current state of the art interface might be the watchdog filter. A task list:
- remember search form settings
- provide a default list of strings to edit before even trying to search
- maybe provide a mass editing interface focusing on one language (submitting tens of translations for one language at once) and the current interface to be able to translate one string to multiple languages at once
- let the user walk to the next/previous editing interface with both approaches
#6
Sorry if this is too off topic (does not target the issues listed above). But I've added a simple feature to the search interface, that made it much more useful to me: The ability to search by (restrict to) certatin "locations".
A location is the thing that (in my theme) is displayed in a smaller font below each phrase in the result list, and it tells on what URL the translatable phrase was first found. The patch is made against v. 5.5, using diff -u, but I do not have a CVS checkout and the first lines that tells the filename is perhaps not in accordance with standards.
I'm developing a module of my own, and thought it would be nice to list all its (relatively few) phrases, and translate them using the web interface. But since there are some thousands of untranslataed phrases from other modules (many administrative phrases) I got a very long list (89 pages) when performing a search for all untranslated strings. But using this patch I can filter away those unrelated phrases.
The issue about search being forgotten if you click on an 'edit'-link remains, but I handle it by opening all edit-pages in background tabs (so the search window remains). That is of course not the ideal solution.
#7
Location could be a few things unfortunately. For translations imported from an existing .po file, the location will be the source file name and line number from where the string was extracted, not any URL. Also, strings might appear on multiple URLs. Eg. on admin/content/node and node/43 This makes the location field a bad value to base search features off.
#8
OK, I didn't knot that about import of .po files.
But I did realize that in the case when the location is a (relative) URL, it seems to be the URL where the phrases was first displayed. So if a module is always (or at least before translation) used in such a way that the URLs contain something particular (e.g. the module name) then all the used phrases can be found by a location search. For instance, a search for "mymodule" would find "mymodule/412" as well as "admin/mymodule/foo".
But I guess what you wrote makes the usefulness of location search limited to this very case.
#9