Now as we are moving into supporting translation of site settings, content types and so on on the locale module interface, it gets extremely important to streamline the translation web interface provided. As far as I see, we have the following problems with the current interface:
- you are presented with a big search form, which you need to first understand to get something to translate
- search results are presented with "edit" links, so you need to click over to the editing screen for all values you need to translate
- on the "edit" page, you get input fields for all languages, but you are possibly interested in translating more strings to one language, not one string to more languages
As far as I see, the use case of translating as many string at once as possible to one language is much more common then translating strings one by one to multiple languages. Also with site settings, content types and so on translated on the locale interface, you are not actually interested in searching in them, but going through all of them, and translating as required.
So I would suggest we move to a direction similar to how watchog (now called dblog) works:
- you get an overview screen of values to translate with a pager
- this screen can be asked for in a particular language, and would show form fields and submit buttons on the bottom ("save translations", "save translations and continue to next page", "continue to next page"), the first going back to the localization overview, the second advancing to the next page with saving, the third only advancing to the next page
- simple filters would be shown on the top, refactored from the search form
How does this sound for you? What interface would you expect from Drupal 6 to translate several parts of the system? While I still would not tell anyone to translate the built-in Drupal interface with the web interface, admin defined strings have no other practical way (most admins will not have any interest in working with a gettext toolchain).