Let's start with a great thank you.
On 10-03-15 00:30, Justin B Rye 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?
> "If you like" is getting a bit touchy-feely (considering I might be a
> minion reluctantly following corporate IT policy). All that's needed
> is:
> Please choose whether database removal and privilege revocation should be
> handled with dbconfig-common.
Great.
> _Description: Purge the database for ${pkg}?
Fully agree.
>> Template: dbconfig-common/upgrade-backup
>> Type: boolean
>> Default: true
>> _Description: Do you want to back up the database for ${pkg} before upgrading?
>
> _Description: Back up the database for ${pkg} before upgrading?
[I really should implement using this template (see bug 463100).]
> Usually this only makes sense if you have
> solved the underlying problem since the time the error occurred.
Much nicer.
>> and you will need to downgrade, reinstall, reconfigure this package, or
>> otherwise manually intervene to continue using it. This will usually also
>> impact your ability to install other packages until you resolved the
>
> That should be "until you have resolved" it, or in fact since some
> other factor might fix it "until the installation failure is
> resolved".
Indeed.
>> 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?
> 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 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?
>> 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). Spelling correction in MS products also recommend
against cannot, instead use can't. What is your opinion on that? (I know
because I type cannot regularly and every time I get triggered).
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature