Re: Last part of the proposed changes to debian-faq
Holger Wansing wrote:
> Hi,
>
> Beatrice Torracca <beatricet@libero.it> wrote:
>> -process, your configuration files might be lost and....
>> +process, your configuration files might be lost and...
>
> I think it should be "might be lost and ..." (space after and)
I tend to follow the Chicago Manual of Style, which doesn't have a
space here, but there's remarkably little agreement.
>> <p>The idea is that, if the package has any problems, it would be discovered by
>> people using unstable and will be fixed before it enters testing. This keeps
>> -the testing in an usable state for most period of the time. Overall a
>> -brilliant concept, if you ask me. But things are always not so simple. Consider
>> +the testing in an usable state for most of the time. Overall a
>> +brilliant concept, if you ask me. But things aren't always so simple. Consider
>> the following situation:</p>
>
> Maybe "But things aren't always that simple."
> or "But things aren't always as simple."
They're all grammatical; "that simple" is probably the most natural.
>> -<p>One of the main reasons many people chose Debian over other Linux distributions is
>> +<p>One of the main reasons many people choose Debian over other Linux distributions is
>
> Maybe "One of the main reasons why many people choose Debian ..."
Yes, again probably more natural English.
[...]
>> <p>The development of Debian is open to all, and new users with the right
>> skills and/or the willingness to learn are needed to maintain existing
>> packages which have been "orphaned" by their previous maintainers, to
>> -develop new packages, and to provide user support.
>> +develop new packages, to write documentation, to do translation work, to
>> +help with the Debian website, to provide user support, etc.
>
> Is it correct/good, to mention the "to" every time? Or can they be removed to
> improve readability?
In this case where the first example is rather a long one the
repetition can be helpful as a way of re-establishing the grammatical
context; then once we've done it once we have to keep doing it. One
alternative would be to rerrange the clauses so the longest example
comes last, although this mixes in the "programmer-y" ones with the
"non-programmer-y" ones:
<p>The development of Debian is open to all, and new users with the right
skills and/or the willingness to learn are needed to develop new packages,
write documentation, do translation work, help with the Debian website,
provide user support, maintain existing packages which have been
"orphaned" by their previous maintainers, etc.
[...]
>> <p>They must be in sync on all architectures where they have been built and
>> mustn't have dependencies that make them uninstallable; they also have to
>> -have fewer release-critical bugs than the versions currently in testing.
>> +have fewer release-critical bugs than the versions currently in unstable.
>> This way, we hope that `testing' is always close to being a release
>> candidate.
>
> 1. they also need to have fewer release-critical bugs (to avoid doubled "have")
Yes, an improvement. Or go back to "must" ("they must also have").
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: