Small step for locale module, big step for usability

I have been to REMIX 07 today, which was basically a rehash of some of the Microsoft MIX conference topics and presentations for a road show stop in Budapest, Hungary. Although I use much less Microsoft technology then I actually go to the conferences, I mostly enjoy going because it inspires me. I see cool new stuff which of course escalates into cool new stuff I would like to implement with my tool set.

One of the simple ideas that occurred to me today was about in-place interface translation editing. It is so common a request to ask for in-place editing tools for translations in Drupal. Just recently, Boris Mann posted a pointer to SLS, which aims to be a more generic solution for the problem (although I commented there why I don't think it fits Drupal well). Unfortunately we only know in t() that we are working with a localized string, so we could print a span or div with metadata to allow some jQuery to tap in and allow translation editing. Unfortunately in t(), we don't know whether we deal with output for email, SMS, watchdog logs and so on, where the extra div or span would look very unprofessional (in a text medium!). So that rules out the PHP way we could add an in-place translation widget (forget about introducing another wrapper, t() is wrapped deep enough).

This problem is so much on people's mind that Konstantin Käfer did include it in his Google Summer of Code 2006 proposal (but unfortunately did not get around to find a way to deal with it). [Unfortunately, I only found a broken link to that proposal.]

So what can we do? The locale() function in PHP stores a cache of all the text used for translation on the page. So the basic idea is to allow that function to return that cache once the page is done. Then a contributed module could request that in the page footer (once all page content and blocks are done), and export that in JSON. A simple block can be provided to give the user some overview of the strings on the page (translated, untranslated), as well as allowing the user to search for a string used on the page to fix translation for (an autocomplete field would suffice here).

So I thought this is all simple and dandy. Let $string be NULL in locale(), and if so, return the cache. This sound all good, but the cache includes all "short strings" for quick lookup, used on the page or not... Either we need some hidden setting to bypass that if using "in-place interface translation" or we need to track what was actually used from that cache. Any good ideas?