svn commit: r40831 - in projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook: . preface

[Benedict Reuschling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 30.01.13 21:54, schrieb Glen Barber:
> On Wed, Jan 30, 2013 at 08:08:54PM +0100, Gabor Kovesdan wrote:
>> Em 30-01-2013 20:01, Benedict Reuschling escreveu:
>>> Author: bcr Date: Wed Jan 30 19:01:33 2013 New Revision: 40831 
>>> URL:http://svnweb.freebsd.org/changeset/doc/40831
>>> 
>>> Log: Deactivate the build of the PGP Keys section from the
>>> appendix. This will not be part of the print edition, but will
>>> still be kept in the online version.
>> Are you sure that this is the best way of doing this? This will
>> make merges more difficult. I don't know if it has been discussed
>> somewhere but I'd prefer a single-source solution. We could add a
>> custom profiling attribute for online or print-only chunks.
>> 
> 
> As a more immediate solution, what if we use something like this
> for changes that should not be merged back to head/ ?
> 
> MFC after:  none
> 

Rather MTC ("to" instead of "from" head), from the perspective of the
branch that is. ;)

We could do that. It requires going through each individual commit
made to the branch when merging it back and figure out what to do with
it depending on the commit message. It also does not put any pressure
on translators. With the attribute solution (which I'm also in favour
of) that Gabor proposed (condition="online" vs. condition="print"),
these need to be put into translations as well, without having an
immediate (visual) benefit for translations. To reduce the actual work
of doing changes in the translated versions (except bumping
revisions), the commit message approach is cleaner. That is, if we
decide to translate the printed version. But when merging them back to
the online handbook, translators would have to pick them up and
integrate them.

However, I'm also seeing that Gabor's solution is a more programatical
way (using XSLT) of dealing with the problem, which also has its
benefits. I'm undecided at the moment, I guess extra work for either
side (translators or people doing the merges) is unavoidable.

Benedict
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEJkRsACgkQTSZQLkqBk0jXmgCg0sopbur6kW8/vizZsylJ5yCo
EgEAoIddKXhxofSQcaK8bsn2tybpioOY
=P2kr
-----END PGP SIGNATURE-----