Re: Debconf Templates Style Guide
> There used to be, somewhere, a guideline that told maintainers to let
> themselves be inspired by the descriptions in the kernel source's
> "make fooconfig", especially with regard to telling the user what the
> conservative default choice is. Many of the kernel option descriptions
> do indeed say "If unsure, answer No" or the like. Or do I misremember?
> If I'm right, then the relation between those two pieces of advice
> should probably be clarified.
Let's see in further discussion. However, there are very strong
arguments against this :
-some frontends do NOT show the user a Yes/No choice
-some other frontends may have translated widgets. Some other may
not. For instance, during a long time, the whiptail Yes/No strings
weren't translated to french. As they are used by debconf dialog
interface, this lead to stuff like this :
Voulez-vous....blabla ?
Blabla......Si vous répondez "Oui"......
Yes No
The original said "If you answer Yes". It was then translated to "Si
vous répondez Oui", but the user saw a Yes/No choice.. :-)
> > The extended description should not repeat the short description.
>
> I'm not sure about this point, which seems to be taken from the
> guidelines about package descriptions. I'd rather say
The idea is motly the same, yes. The key here wass that extended
description is never shown alone, but always as a complement to the
short one. However, you give some counter-examples.
> The extended description should be able to stand on its own,
> *without* the short one. For example, the dialog frontend will
> sometimes choose to show the entire extended description first and
> only ask the actual question on a separate screen after the user has
> confirmed reading the extended one. This depends on the terminal
> size and the lenght of the extended description, so it may happen to
> users even if it does not happen to you.
Hmmm, this is a good point. Well, for string/select/multiselect, this
shoul dnot happen as extended descriptions should always ablance
between verbosity and quality.
This may be true for notes.....where the short desc is however more a
title than a summary.
>
> Thus, even if the short description says "Complain about split
> infinitives", the extended description contain something like
> "Foobar can be configured to never complain about split
> infinitives...", such that the user knows roughly which decision
> he's going to make while he's absorbing the information in the
> rest of the extended description.
This is not a strict repeat, so I wouldn't consider this as a
violation of the "rule" I wrote.
In fact, this is a very good use of short and extended
descriptions.. :-)
Reply to: