Although providing multiple adp's per page may be useful, I think in the majority of cases layouts will remain the same or be handled automagically by widgets, and *requiring* one adp per page would be a pain.
I agree that trn tags should have real keys, and suggest that they be formatted like the rest of our procedure names (in English), and have an optional second part, the package key. This would allow pieces of text to be defined once in the message catalog and be reused in the same or other packages, like a procedure call.
I think it would be a mistake to emulate the db_* calls and allow embedded translations between trn tags. It's just too confusing to have these bogus queries/translations accumulate in the most prominant place in the toolkit, which may or may not have anything to do with the final output.
Last time I looked, the request processor didn't have any of the code needed for locale negotiation, multiple adp pages etc. It's all still to do.
Slurping the translated snippets of text into nsv arrays at startup is going to be too slow -- that's an extra dozen locks acquired per page request. Better I think to have the trn tag lookup the translation at compile time and have the text embeded directly in the page. This would require extra support from the request processor to store multiple compiled versions from one source version of an adp, but then it's all extra support at the momemnt...
While we're on the subject of translations, 'englisch' is incorrect, Malte. It should be 'engrish' 😊
http://www.engrish.com/
