Re: Advice for dbconfig-common template
Paul Gevers wrote:
>> In passing I've standardised the whitespace towards the d-l-e "house
>> style" of singlespaced sentences.
>
> Thanks. I was already annoyed by them (but not enough to have fixed them
> everywhere. I don't expect so but isn't this something that debconf
> takes care of?
Not in verbatim paragraphs, and I get carried away.
[...]
>>> Template: dbconfig-common/mysql/method
>>> Type: select
>>> __Choices: unix socket, tcp/ip
>>> Default: unix socket
>>> _Description: Connection method for MySQL database of ${pkg}:
>>> By default, ${pkg} will be configured to use a MySQL server
>>> through a local unix socket (this provides the best performance).
>>> However, if you would like to connect with a different method, or to a
>>> different server entirely, select an option from the choices below.
>>
>> Standardise on "Unix" in the description. Can we make the "Choices"
>> strings "Unix socket, TCP/IP"? (I've left them for now.)
>
> Hmm. I will have to sleep on that as this impact the use of old answers.
> I couldn't find a nice way in sh to lower or upper the text of a
> variable. Also, do you now what debconf behavior is which such a change?
(with)
No, it would need to use tr (or a bashism). And it gets trickier:
what happens in the Portuguese version where a "Unix socket" is "um
soquete Unix"? There's some debconf trick for distinguishing
translatable choice names from the fixed-string options they set, but
I can't remember it now.
>> I'm not sure we're entitled to assume that debconf front-ends will
>> present the choices below the text (and in this case of course there's
>> only one other choice available).
>
> When I was reading the template, I had exactly the same idea.
>
>> How about:
>>
>> To connect with a different method, or to a different server entirely,
>> select the option here.
>
> What do you mean with "the option",
I was thinking "select the option [corresponding to the method you
have chosen] here". We might alternatively say "select that option
here" or of course where there's only one choice we could name it.
> I understand it refers to TCP/IP,
> but I am not sure that that is 100% clear. Should we just say "select
> the TCP/IP option here". Ah, and after reading the option below about
> pgsql, I may have to add the "TPC/IP + SSL" option (have to confirm).
>
>> (The German translator will probably want to imagine a "respective" in
>> there!)
>
> Than this drops out as well.
>
>>> With "password" authentication, a password will be passed to the server
>>> for use with some authentication backend (such as "md5" or "pam"). Note
>>> that the password is still passed in the clear across network
>>> connections if your connection is not configured to use SSL.
>>
>> Are we sure we don't mean "MD5" or "PAM"?
>
> You mean capitalize it? What would be against it?
We might be talking about options that go in some configuration file,
in which case the canonical string might be lowercase (sometimes e.g.
utf8 and UTF8 even have different effects!)
>>> It has been determined that the database installation for ${pkg}
>>> can not be automatically accomplished without making changes to
>>
>> "Can not" can be ambiguous; I would make it "cannot".
>
> Out of curiosity, can you explain? I don't see the ambiguity (clearly
> not a native speaker).
"Cannot X" always means "is unable to X", whereas "can not X"
sometimes means "is able to not-X": "sometimes it can not only be
technically ambiguous but genuinely confusing".
http://www.oxforddictionaries.com/words/cannot-or-can-not
> Spelling correction in MS products also recommend
> against cannot, instead use can't.
Bizarre! There are (slightly old-fashioned and formal) usage guides
that deprecate contractions (can't/won't/isn't/etc.), but I'm unaware
of any source that argues for making them mandatory.
> What is your opinion on that? (I know
> because I type cannot regularly and every time I get triggered).
My opinion is that grammarcheckers are a major source of bad grammar,
and MS are a major source of bad grammarcheckers.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: