出自UXGuide.net

错误信息：文本

Error Messages: Text

目录 1 概述 (General) 2 Titles 3 Main instructions 3.1 Main instruction templates 4 Supplemental instructions 5 Commit buttons

概述 (General)

• Remove redundant text. Look for it in titles, main instructions, supplemental instructions, command links, and commit buttons. Generally, leave full text in instructions and interactive controls, and remove any redundancy from the other places.
• 去除冗余文字。 在标题、主要说明、补充说明、命令链接和提交按钮寻找它。一般将全文至于指令和交互控制，并消除任何来自其他地方的冗余。
• 使用以用户为中心的解释文字. Describe the problem in terms of user actions or goals, not in terms of what the software is unhappy with. Use language that the target users understand and use. Avoid technical jargon.
• 使用以用户为中心的解释文字。 以用户的动作或目标来描述问题，而不是软件有什么问题。使用目标用户理解和使用的语言。避免技术术语。

错误：

正确：

In these examples, the correct version speaks the user's language whereas the incorrect version is overly technical.

在这些例子中，正确的版本使用用户的语言说话，而错误的版本过于技术性。

• 不要使用下列字词：
  • error（错误）、failure（失败）：用“Problem（问题）”代替
  • failed to（……失败）：用“unable to（无法）”代替
  • illegal（非法）、invalid（无效）、bad（损坏）：用“incorrect（错误）”或“not valid（并非有效）”代替
  • fatal（致命）：用“program termination（程序终止）”代替
  • abort（中止）、kill（中止）、terminate（终止）：用“stop（结束）”代替
  • catastrophic（灾难性的）：用“serious（严重的）”代替

这些用语是不必要的，而且与 Windows Vista 的鼓励式语气背道而驰。相反，当错误图标使用得当时，足以表达这里出现了问题。

错误：

正确：

In the incorrect example, the terms "catastrophic" and "failure" are unnecessary.

在错误的例子，“灾难性的”和“失败”的条款是不必要的。

• 不要使用责备用户或暗示用户犯了错误的用语。避免在句子中使用“you（你）”和“your（你的）”。虽然通常来说建议使用主动语态，但如果主动语态有可能会使用户感到被责备的话，可以使用被动语态。

错误：

正确：

The incorrect example blames the user by using the active voice.

在错误的例子用主动语态指责用户。

• 用词明确。避免模糊的用词，例如“语法错误”或是“非法操作”。应当提供明确的名称、位置及所涉及的对象的值等等。

错误：

File not found.

找不到文件。

Disk is full.

磁盘满。

Value out of range.

值超出范围。

Character is invalid.

字符不合法。

Device not available.

设备不可用。

These problems would be much easier to solve with specific names, locations, and values.

给出具体名称、地点和值，这些问题会更容易解决。

• Don't give possibly unlikely problems, causes, or solutions in an attempt to be specific. Don't provide a problem, cause, or solution unless there is one that is likely to be right. For example, it is better to say An unknown error occurred than something that is likely to be inaccurate.
• 不要试着具体化可能不真实的问题、原因或解决方案。 不要提供一个问题、原因或解决方案，除非有一个可能是正确的。例如，说“发生未知错误”比很可能是不准确的说法更好。
• Avoid the word "please," except in situations in which the user is asked to do something inconvenient (such as waiting) or the software is to blame for the situation.
• 避免“请”字。 除非在要求要求做一些不便（如等待）或软件出错的情况。

正确：

Please wait while Windows copies the files to your computer.

请等待知道Windows复制文件到计算机。

• Use the word "sorry" only in error messages that result in serious problems for the user (for example, data loss or inability to use the computer). Don't apologize if the issue occurred during the normal functioning of the program (for example, if the user needs to wait for a network connection to be found).
• 只在在导致用户严重问题的错误消息中使用词语“抱歉”。 （例如，数据丢失或无法使用电脑）。如果在程序正常运作中发生问题，不要道歉（例如，如果用户需要等待发现网络连接）。

正确：

We're sorry, but Fabrikam Backup detected an unrecoverable problem and was shut down to protect files on your computer.

我们很抱歉，但Fabrikam的备份检测到一个不可恢复的问题并关闭以保护您的计算机上的文件。

• Refer to products using their short names. Don't use full product names or trademark symbols. Don't include the company name unless users associate the company name with the product. Don't include program version numbers.
• 提及产品时使用短名称。 不要使用完整的产品名称或商标符号。不要包含公司名称，除非用户与产品的公司名称相关联。不要包含程序的版本号码。

错误：

正确：

In the incorrect example, full product names and trademark symbols are used.

在错误的例子中，使用了完整的产品名称和商标符号。

• Use double quotation marks around object names. Doing so makes the text easier to parse and avoids potentially embarrassing statements.
• 围绕对象名称中使用双引号。 这样做可以使文本更容易解析和避免潜在的令人为难的声明。
  • Exception: Fully qualified file paths, URLs, and domain names don't need to be in double quotation marks.
  • 例外： 完全限定的文件路径，网址，域名不需要用双引号。

正确：

In this example, the error message would be confusing if the object name weren't in quotation marks.

在这个例子中，如果对象的名称没有引号，错误信息会引起混乱。

• Avoid starting sentences with object names. Doing so is often difficult to parse.
• 避免以对象名称为句首。 这样做往往很难解析。
• Don't use exclamation marks or words with all capital letters. Exclamation marks and capital letters make it feel like you are shouting at the user.
• 不要使用感叹号或所有字母大写。 惊叹号和大写字母，令人感觉你在对用户叫喊。对于更多的指引和例子，请参阅Style and Tone.

Titles

• Use the title to identify the command or feature from which the error originated. Exceptions:
  • If an error is displayed by many different commands, consider using the program name instead.
  • If that title would be redundant or confusing with the main instruction, use the program name instead.
• Don't use the title to explain or summarize the problem—that's the purpose of the main instruction.

Incorrect:

In this example, the title is being incorrectly used to explain the problem.

• Use title-style capitalization, without ending punctuation.

Main instructions

• Use the main instruction to describe the problem in clear, plain, specific language.
• Be concise—use only a single, complete sentence. Pare the main instruction down to the essential information. You can leave the subject implicit if it is your program or the user. Include the reason for the problem if you can do so concisely. If you must explain anything more, use a supplemental instruction.

Incorrect:

In this example, the entire error message is put in the main instruction, making it hard to read.

• Be specific—if there are objects involved, give their names.
• Avoid putting full file paths and URLs in the main instruction. Rather, use a short name (such as the file name) and put the full name (such as the file path) in the supplemental instruction. However, you can put a single full file path or URL in the main instruction if the error message doesn't otherwise need a supplemental instruction.

In this example, only the file name is in the main instruction. The full path is in the supplemental instruction.

• Don't give the full file path and URL at all if it's obvious from the context.

In this example, the user is renaming a file from Windows Explorer. In this case, the full file path isn't needed because it's obvious from the context.

• Use present tense whenever possible.
• 使用句子大写样式。
• Don't include final periods if the instruction is a statement. If the instruction is a question, include a final question mark.

Main instruction templates

While there are no strict rules for phrasing, try using the following main instruction templates whenever possible:

• <optional subject name> can't <perform action>
• <optional subject name> can't <perform action> because <reason>
• <optional subject name> can't <perform action> to "<object name>"
• <optional subject name> can't <perform action> to "<object name>" because <reason>
• There is not enough <resource> to <perform action>
• <Subject name> doesn't have a <object name> required for <purpose>
• <Device or setting> is turned off so that <undesired results>
• <Device or setting> isn't <available | found | turned on | enabled>
• "<object name>" is currently unavailable
• The user name or password is incorrect
• You don't have permission to access "<object name>"
• You don't have privilege to <perform action>
• <program name> has experienced a serious problem and must close immediately

Of course, make changes as needed for the main instruction to be grammatically correct and comply with the main instruction guidelines.

Supplemental instructions

• Use the supplemental instruction to:
  • Give additional details about the problem.
  • Explain the cause of the problem.
  • List steps the user can take to fix the problem.
  • Provide measures to prevent the problem from reoccurring.
• Whenever possible, propose a practical, helpful solution so users can fix the problem. However, make sure the proposed solution is likely to solve the problem. Don't waste users' time by suggesting possible, but improbable, solutions.

Incorrect:

In this example, while the problem and its recommended solution are possible, they are very unlikely.

• If the problem is an incorrect value that the user entered, use the supplemental instruction to explain the correct values. Users shouldn't have to determine this information from another source.
• Don't provide a solution if it can be trivially deduced from the problem statement.

In this example, no supplemental instruction is necessary; the solution can be trivially deduced from the problem statement.

• If the solution has multiple steps, present the steps in the order in which they should be completed. However, avoid multi-step solutions because users have difficulty remembering more than two or three simple steps. If more steps are required, refer to the appropriate Help topic.
• Keep supplemental instructions concise. Provide only what users need to know. Omit unnecessary details. Aim for a maximum of three sentences of moderate length.
• To avoid mistakes while users perform instructions, put the results before the action.

Correct:

To restart Windows, click OK.

Incorrect:

Click OK to restart Windows.

In the incorrect example, users are more likely to click OK by accident.

• Don't recommend contacting an administrator unless doing so is among the most likely solutions to the problem. Reserve such solutions for problems that really can only be solved by an administrator.

Incorrect:

In this example, most likely the problem is with the user's network connection, so it's not worth contacting an administrator.

• Don't recommend contacting technical support. The option to contact technical support to solve a problem is always available, and doesn't need to be promoted through error messages. Instead, focus on writing helpful error messages so that users can solve problems without contacting technical support.

Incorrect:

In this example, the error message incorrectly recommends contacting technical support.

• 使用带句末标点的完整句子，并使用句子大写样式。

Commit buttons

• If the error message provides command buttons or command links that solve the problem, follow their respective guidelines in Dialog Boxes.
• Otherwise, provide a Close button. Don't use OK for error messages, because this wording implies that problems are OK.
• Don't provide a debug command unless the program is specifically targeted at the developer of the program.

Incorrect:

In this example, it's doubtful that many users would be inclined to debug the problem.