Give modules short noun names. Use title-style capitalization. Examples of good module names are:

This includes dialog titles, frame labels, and pop-up titles. Keep the text short and concise. Do not use ending punctuation (: or .).

Use sentence-style capitalization. Do not use any ending punctuation. Do not use multiple sentences.

The status bar texts for the Control Center currently appear in the desktop files after GenericName=.

These rules apply to all input and command widgets. These widgets include check boxes, buttons, radio buttons, and text entry fields.

Keep the labels short and concise. Use a label like Name instead of Enter Name or Select Name.

Ending punctuation, such as : or ., should not be used. Use ... at the end of command widgets that open a pop-up or new dialog requiring user input. Do not use ... on navigational buttons, such as Next or Back. Do not use a space before it. For example, Detailed Configuration....

	Important
	The final button of a wizard should always be Accept.

These rules apply when you giving the user information about the current status of a selection or service. This means it is also used for summaries and proposals. For example:

Packages to Update: 4

The category of the information should be title-style (Packages to Update:) because it works like a header. End the category in a colon (:).

The information itself should be sentence-style. Keep status information shorter than a sentence and do not end it in a period (.).

Label progress bars with a short noun phrase in title-style capitalization. The text should be informative. Examples:

When the process is already described, as in the progress stages of initialization, do not label the progress bar.

rwalter: add shots

Progress stages appear in situations like module initialization. They tell the user what YaST does in order. Write them like a to-do list using sentence-style capitalization. Do not use any ending punctuation on the stages.

Examples of good progress stages include:

Use these when showing that YaST is currently doing something and the user needs to wait. Write a phrase using a verb ending in -ing because the thing is currently being done. End it in ... to show that it is an ongoing operation. Use sentence-style capitalization.

Examples of appropriate busy messages include:

Error messages should give the user only as much information as is useful. Do not confuse the average user with overly technical error messages. For errors that can be resolved by an experienced user, provide the technical information with a Details... button. Errors related to program bugs should have the detailed information placed in the log and not marked for translation. Use the text "Internal error occurred. See the logs for information." as the error message.

Use sentence style capitalization. End in a . if it is a complete sentence or more than one sentence.

rwalter: need standard text for bug errors

Use sentence-style capitalization for warnings. End in a period (.) if it is a complete sentence or more than one sentence.

Confirmation messages should clearly describe the situation to confirm. Use complete sentences or multiple sentences and end each sentence with a period (.). The last sentence should be a clear question that can only be answered with the available options. Clear questions for yes-no confirmations include:

Use title-style capitalization for column and row headers. Use sentence-style capitalization for entries. Do not use ending punctuation.

Use title-style capitalization for all tree items.

Help needs to give the user clear directions on how to use the dialog. Also provide information about specific user input that is required, such as IP addresses, domain names, or text in a restricted character set.

Start the help with a concise paragraph describing what the dialog is all about. It should let the reader know why he would use this dialog.

If it works for your dialog, orient the help towards tasks the user may want to perform. If the layout is complex, describe the elements of the dialog. If the dialog only addresses a single task, as in the dialogs for editing configuration values, focus on the elements of the dialog. Provide background information if it is likely to be needed by the average user.

Headings should be placed in big and b tags and capitalized title-style. All help texts should have a heading at the top. In many cases, additional headings are unneeded.

The texts should be written in paragraphs (p tags) using complete sentences. Do not use br to force line breaks. If possible, have two or more sentences per paragraph. This is not, however, always reasonable in help texts.

Place widget labels in b tags. Use tt for example values and URLs. Because the tags are very attention-grabbing, avoid overusing them.

If you want to use the widget labels like headers when making UI-based help, place the label in b tags and follow it with a colon (:). See Example 1, “Example of UI-Based Help”.

<p><b>IP Address</b>: Enter the IP address of the host,
    such as <tt>10.1.1.100</tt>.</p>
     <p><b>Hostname</b>: Enter the hostname for the host,
    such as <tt>earth</tt>.</p>

The command line interface has its own rules. For command line help texts, use sentence-style capitalization. Do not use ending punctuation except in rare cases when multiple sentences are used. When multiple sentences are used, end all sentences in a period (.).

Headers, summary headers, and similar items should be written title-style and end in a colon (:). Table headers should not have colons but should be capitalized title-style.