SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Reword sentences that contain psuedo-English "resp."

Browse Source 
As you likely know, Arch Linux is in the process of moving to systemd.
So I was reading through the various systemd docs and quickly became
baffled by this new abbreviation "resp.", which I've never seen before
in my English-mother-tongue life.

Some quick Googling turned up a reference:
<http://www.transblawg.eu/index.php?/archives/870-Resp.-and-other-non-existent-English-wordsNicht-existente-englische-Woerter.html>

I guess it's a literal translation of the German "Beziehungsweise", but
English doesn't work the same way. The word "respectively" is used
exclusively to provide an ordering connection between two lists. E.g.
"the prefixes k, M, and G refer to kilo-, mega-, and giga-,
respectively." It is also never abbreviated to "resp." So the sentence
"Sets the default output resp. error output for all services and
sockets" makes no sense to a natural English speaker.

This patch removes all instances of "resp." in the man pages and
replaces them with sentences which are much more clear and, hopefully,
grammatically valid. In almost all instances, it was simply replacing
"resp." with "or," which the original author (Lennart?) could probably
just do in the future.

The only other instances of "resp." are in the src/ subtree, which I
don't feel privileged to correct.

Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
This commit is contained in:
Andrew Eikum
2012-10-16 01:03:01 +02:00
committed by Lennart Poettering
parent edfb521a21
commit 16dad32e43
23 changed files with 100 additions and 97 deletions
Download Patch File Download Diff File Expand all files Collapse all files
man/systemd.unit.xml
+10 -10
View File
@@ -77,8 +77,8 @@
<para>This man pages lists the common configuration
options of all the unit types. These options need to
be configured in the [Unit] resp. [Install]
section of the unit files.</para>
be configured in the [Unit] or [Install]
sections of the unit files.</para>
<para>In addition to the generic [Unit] and [Install]
sections described here, each unit should have a
@@ -418,7 +418,7 @@
<listitem><para>Similar to
<varname>Requires=</varname>
resp. <varname>RequiresOverridable=</varname>. However,
and <varname>RequiresOverridable=</varname>, respectively. However,
if a unit listed here is not started
already it will not be started and the
transaction fails
@@ -566,7 +566,7 @@
<varname>Before=</varname>. If two
units have no ordering dependencies
between them they are shut down
resp. started up simultaneously, and
or started up simultaneously, and
no ordering takes
place. </para></listitem>
</varlistentry>
@@ -672,13 +672,13 @@
<listitem><para>Takes a boolean
argument. If <option>true</option>
this unit can only be activated
(resp. deactivated) indirectly. In
or deactivated indirectly. In
this case explicit start-up
(resp. termination) requested by the
or termination requested by the
user is denied, however if it is
started (resp. stopped) as a
started or stopped as a
dependency of another unit, start-up
(resp. termination) will succeed. This
or termination will succeed. This
is mostly a safety feature to ensure
that the user does not accidentally
activate units that are not intended
@@ -1023,8 +1023,8 @@
<listitem><para>Installs a symlink in
the <filename>.wants/</filename>
resp. <filename>.requires/</filename>
subdirectory for a unit. This has the
or <filename>.requires/</filename>
subdirectory for a unit, respectively. This has the
effect that when the listed unit name
is activated the unit listing it is
activated