a) As Philip mentions, the revision handling is a very basic thing that is taken for granted right now, but the time will come when we can't rely on CVS's automatic handling of $Revision$ strings anymore. This system could be emulated on different VCS using pre-commit hooks, which most if not all VCS software offer in one form or another. Or maybe we can come up with a new system, if it adds extra value to implement a new revision mechanism. I can't think of anything special in this regard, so right now I'd go for using the same style of rev numbers (1.XX), and just figuring out the way to keep using it on whatever VCS that comes along.
I do not believe this is a major concern because the various projects that use po files typically have tools setup that deal with this. So, in this case, I think we'd simply choose a set of pre-existing tools and slightly modify to fit our needs. But, the problem you describe is serious for the initial migration as I fear it'd be so painful that many translations would start from scratch. However, hopefully we'd figure out a nice way to at least import all of the up-to-date translated content...
b) Now, as far as CATs go, I know there are lots of options out there, some using .po as the format at the translation level, and interfacing with DocBook/XML, so the documentation team keeps working in the original format (phpbook). That's great and I've been looking at some of these tools, such as OmegaT, or Gnome's intltool, which could be used interchangeably by translators, along with any other tools people feel comfortable with, once our documentation tree is in the right shape.
Good point, and I did try a few tools that required such validation but am not sure if all do. However, Hannes is working on this and I think plans to post a wiki entry with the details of his findings for discussion.
Regards, Philip
