[tz] [PATCH v2 2/4] zic.8: s/time zone/timezone/ for consistency

[G. Branden Robinson]

Hi Alex,

At 2022-11-23T14:48:27+0100, Alejandro Colomar wrote:
> This adds consistency across other manual pages, and with POSIX.1.
> 
> Signed-off-by: Alejandro Colomar <alx at kernel.org>
> ---
>  zic.8 | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
[...]
> -A time zone abbreviation uses a
> +A timezone abbreviation uses a
[and so on similarly]

I mildly object to this on English style grounds.  Like "filename" or
"filesystem", it seems like a corruption of an English compound noun by
programmers accustomed to writing identifiers in programming
languages.[1]  Such people might also write "icecream", which is widely
recognized as a solecism, if ice cream were to ever be discussed in the
context of an API.  The space is semantically significant: a
"greenhouse" is not the same thing as a "green house".

I believe there are a few advantages to preferring spaces in compounds
except where _general_ English usage (as opposed to that of Unix nerds)
has beaten a track the other way.

1.  They may be easier to parse for non-native English speakers.  I was
    going to say that this point would not apply to a German speaker,
    who can morphologically analyze a 100-letter compound without
    reducing the blood glucose level in their brain an iota, but on
    second thought that may not be true.  English is notorious for
    borrowing from any language in the world, and a triple compound
    combining Germanic, Latinate, and Mi'kmaq roots is conceivable.
    This process may challenge even a native German's world-class
    ability to detect morpheme boundaries.

2.  When divided, spaceful compounds don't need to be added to anyone's
    spell checking dictionary if their roots are already present (as
    they certainly will be here).

3.  When divided, spaceful compounds are at less risk of incorrect
    hyphenation when typeset.  (We speak of TeX and troff and other
    systems as having hyphenation "algorithms", and while this is
    literally true, they are algorithms with huge lists of rules and
    exceptions, and they are applied to large and ever-growing open
    classes of inputs.  They therefore _behave_ heuristically [albeit
    deterministically], I submit, and can produce incorrect hyphenation
    break points through no fault of the algorithm itself.)

4.  Compounds that retain their spaces will fill and break lines more
    evenly, reducing the risk of large gaps between words when
    adjustment is performed, especially on terminal devices that can
    only adjust lines coarsely (an entire character cell at a time).
    If, in context, one fears that a line break within a compound used
    in a man page will damage the comprehensibility of a sentence, then
    one should probably recast the sentence, but in a pinch one can use
    a non-breaking space to avoid the problem, as with "time\~zone".

I acknowledge that any of the above can be of little concern to some.

So if it were me I would start driving man pages toward consistency in
the other direction (spoiler alert: I've already done this for many
groff man pages) and not worry about consistency with POSIX.1 here.

Regards,
Branden

[1] _Most_ programming languages, that is.  Some are lexically analyzed
    such that spaces are permissible in identifiers.  In Fortran's old
    fixed-source form, this was the case because spaces were completely
    ignored in input (outside of string literals, maybe).  There is a
    famous, albeit semi-apocryphal, bug story arising from this.[2]
    Fortran implementations, like those of C and Perl after them, spent
    many years being quite liberal in what they accepted.

[2] The bug was real but legend often hyped it up into causing loss of a
    spacecraft (cf. "space craft" ;-) ).

    https://www-users.cs.york.ac.uk/susan/cyc/p/fbug.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20221123/998821ec/signature-0001.asc>