I hope the Peter's statement "the best way to provide context that we have come up with is the translator mode" is not meant to be a surrender in the struggle of finding contexts?
If the system is well designed (and I think it is) there should be some possibility to drill down the "Files that use this message" to only .adp-files. If some other module uses a given string and transfers it via some hidden mechanism to the .adp page, this relation should be able to be put into the database.
Example: string dotlrn.user_portal_page_file_storage_title ("My Files") is found only in "dotlrn.info". In some mysterical way, it is nevertheless displayed on dotlrn-master.adp where non-programmers can see it in context. In the message catalog, there could be a pointer to some intermediate module or variable (say, navprocs.tcl or @navbar@), and there, in turn, could be pointers to other modules/variables, until eventually the final end user .adp-page turns up in the translator's dialogue.
Until this context finding problem is sufficiently solved, translators URGENTLY need help to follow these winding roads of strings. I compiled a long list of strings that are simply not understandable without their context, http://www.rzuser.uni-heidelberg.de/~x28/i18n/blindflug.txt
Trying to resolve them is not possible even by using the source code. For example, acs-subsite.lt_Then_you_should_eithe leads to /web/translate/packages.old/acs-subsite/www/pvt/home.adp , but browsing the cvs to http://cvs.openacs.org/cvs/openacs-4/packages/acs-subsite/www/pvt/home.adp ,the string is not there.
(If the "packages.old" indicates that the message catalogue is not properly cleaned up, this should be immediately done.)
