Sean, I just had the time to look into your ideas. Since this needed some time to think about, I just had no opportunity to find enough time before.
My time has been limited as well, hence my silence on this topic. It will be further limited in the coming weeks, as well, as we're expecting any day, now. I'll likely disappear for a number of weeks.. part of my urgency on this issue, but it's too late now, anyway (-:
First, I love that someone works on the code, and there is some progress. Second, I do think that our translators are already familiar with a toolset (CVS, XML editing, replacing english text with their translations), so we should try and keep the docweb participation process as close to that for translation teams. Putting files into phpdoc language modules and using already known technologies (PHP files or XML) will help. Using another tool (gettext) will not work that good. I know gettext, and I know that it is easy. And I also know xml, cvs, etc. and I know that these are easy. Not all our translators think so :)
Looking back on my template proposal, I propose the following ammendments:
1) Dump my language class. Write something new that uses XML Entities. The entities are stored in [phpdoc-all]/docweb/*.ent; where *.ent is general.ent, revcheck.ent, etc (for each section). If a given entity is missing, we fall back to the english. If entities are insufficient, we could create a simple DTD (something like: <text language="??"><app name="docweb"><entry name="welcome">Welcome!</entry></app></text>)
2) Keep my templating engine, but remove all text from the templates, using the entities in its place. The templates will remain in [docweb], and only those with docweb karma can change these. Karma should remain "easy" to get.
3) Templates remain PHP, so we don't have to learn/manage/maintain another templating solution, with my same soft-rules in place. (I realize that templating engines/languages such as Smarty are easy to learn and use, but I also don't want to have the debate on which is best, I want to just get moving.. these should be easy to retrofit, if we ever feel compelled).
4) Other-language templates will rarely be used, but I'd like to keep the request-fallback mechanism in place in case we need to modify markup based on display (right-to-left, long texts, etc)
I am still firm on "display code should be in templates", though.
S