I've been giving this a bunch of thought, not to 'tune' the messages, but simply localize them. The tuning of messages would be a snap.
My thought is to build two reference tables, the first of replacement messages hashed by source messages, and the second of replacement messages hashed by source message pointer. On startup, read an arbitrary localization file of source:replacement error strings (corresponding to the strings scattered throughout our sources). These obviously include any subst tokens, so the file permissions of such a localization file must be as strong as the httpd and module binaries themselves. To keep things simple, I'd suggest a trivial format of en: File %s not found. de: <blank line> Where each line consists of a language code, colon ':', and LWS which is followed by that language's error message. The next en: code or a blank line would terminate parsing for that specific message. We need to read only one pair of codes at startup, although it is conceivable to have different error logs using different languages. Extending the behavior to do this would be pretty trivial. On every error log invocation, we look up the second pointer->replacement message table, and if not found, proceed to search for the string in the first source->replacement table. If not found, we use the source string, either way add the entry for the pointer->replacement string hash. There is a reasonable penalty on the first lookup. A btree lookup would really help with the one time string lookup if the error tables grow quite large. Such a string pointer->replacement lookup could be extended to add various flags such as desired log level. I'll be looking at the cpp to work out extraction of the strings of all ap_log calls in our core and modules. Other thoughts?
