Thomas Lockhart writes:
> Great! Are you translating the sgml source docs? If so, should we
> include those in the CVS tree, or can you suggest another way of keeping
> track of the latest versions?
Perhaps we (or someone) could set up a separate CVS module (other than
"pgsql") for these things. We probably don't want to commit to having
these things up to date at release date, and IMHO shipping inaccurate docs
is often worse than shipping none.
Then you could also give access to that CVS module to a wider/different
group of people. That would allow things to move faster for those groups,
since for documentation translations you wouldn't need to wait for code
developers to approve patches that they can't read anyway.
> Also, there was a request from the Spanish translators to coordinate
> changes in the source docs, so they can make updates to the
> translations. I can generate context diffs from CVS, but if you have
> other ideas please speak up.
True, diffs aren't hard to make. But ISTM that diffs are not the ideal
format for humans to process. For example, in my experience, doc diffs
often contain typo and minor word choice fixes, white space/formatting
changes, or sections moved elsewhere, which would make things very hard
for translators to process. Furthermore, since translators probably won't
track documentation updates day-to-day, but rather by release, you will
probably get huge diffs.
A pragmatic approach might be that you simply keep track in your
translated copy which revision (RCS) of the original it corresponds to. If
you get down to updating that file you will probably have to reread the
whole file anyway in order to get an overview of the subject matter. At
that point you can still look at the diffs to get an idea about the extent
of the changes.
As for specific mechanisms, subscribing to the pgsql-committers list might
be a first step. Filter everything that matches "Subject: [COMMITTERS]
pgsql/doc/src/.*" or similar. Put these files into a list of "potentially
outdated", then look at each of them individually as described above.
Just some ideas...
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
