Re: Rewrite manual intro to be gender-neutral.

[Ralf Wildenhues]

Hello Bob,

* Bob Friesenhahn wrote on Sun, Jun 06, 2010 at 05:15:11PM CEST:
> On Sun, 6 Jun 2010, Ralf Wildenhues wrote:
> 
> >This mirrors a similar recent fix to automake.texi.
> >Any technical reasons against this patch?
> >The rest of the manual greps ok.
> 
> Regardless of Gary's affirmation, I don't think that replacing 'he'
> with 'you' is suitable.  'He' and 'you' are not at all equivalent
> terms.  If there are two people in a room and one of them is 'you'
> then the other one may be 'he' or 'she' but is definitely not 'you'.
> If one is talking about the past, then the gentle reader might still
> have been in elementary school at the time (or the womb) and so it
> is not suitable to use the term 'you'.

I'm really confused now.  Is there any specific formulation, sentence,
or something in the manual that my change made worse in any way?  If you
think so, can you please point it out precisely, including a suggestion
on how to improve it?  Your comment seems very general, and while I can
guess that in general, the transformation from third to second person
singular can be problematic, I fail to see why this should be the case
in this patch.

In all autotools manuals, use of "you" is already abundant.

Thanks,
Ralf

> >--- a/doc/libtool.texi
> >+++ b/doc/libtool.texi
> >@@ -230,13 +230,13 @@ Platform quirks
> >@node Introduction
> >@chapter Introduction
> >
> >-In the past, if a source code package developer wanted to take advantage
> >-of the power of shared libraries, he needed to write custom support code
> >-for each platform on which his package ran.  He also had to design a
> >-configuration interface so that the package installer could choose what
> >-sort of libraries were built.
> >+In the past, if you were a source code package developer and wanted to
> >+take advantage of the power of shared libraries, you needed to write
> >+custom support code for each platform on which your package ran.  You
> >+also had to design a configuration interface so that the package
> >+installer could choose what sort of libraries were built.
> >
> >-GNU Libtool simplifies the developer's job by encapsulating both the
> >+GNU Libtool simplifies your job by encapsulating both the
> >platform-specific dependencies, and the user interface, in a single
> >script.  GNU Libtool is designed so that the complete functionality of
> >each host type is available via a generic interface, but nasty quirks