> 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..�:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
