6. 语言审核
由于作者来自各种不同的背景，文档中可能存在需要修复的问题。作者可能在其主题领域非常知识渊博，但写作能力不佳，或者他们可能是优秀的作家，但语言可能不完全流利。语言审核通过关注使文档更易于用户阅读和理解的语言问题来解决这些类型的问题。文档中可能出现的一些问题包括句子结构差、语法错误、组织混乱、清晰度不足和拼写错误。
如果您正在进行语言审核，您应该精通该语言及其结构。您需要考虑文档的逻辑和语法。语言审核的主要目标是识别和纠正可能导致文档读者/用户困惑的区域。为此，当您有疑问时，您当然可以使用语言和语法参考书，例如字典和手册。
尽管此审核确实涉及语言的结构和表达方式，但您不应尝试为了使文档“听起来更好”或更技术化而清除文档的个性和特点。呆板、缺乏幽默感的语言和结构不是我们的目标。再次强调，您的目标应该是使文档清晰、明确、拼写和语法正确。
评估项目
拼写。 拼写应符合术语的标准化英语拼写。对于语言中较新且尚未标准化的词语（例如，在社区中普遍接受的技术 Linux 术语），请遵循该术语最常见的拼写。
注意 由于英语有两种普遍接受的形式，因此此审核不应偏袒美式英语拼写而非英式英语拼写，反之亦然。例如，如果作者使用英式英语并使用单词 "realise"，您不应仅仅因为您说/写美式英语而将单词的拼写更改为 "realize"。
语法。 就本次审核而言，语法应解决诸如主谓一致、代词/先行词一致等问题。HOWTO 中常见的且令人困惑的错误之一是不明确的代词先行词。
例如，说："You will need to set several parameters in the config file to make it compile correctly. The ones you choose to set make a big difference." 在这个例子中，听起来像是配置文件正在编译，并且需要重新阅读短语才能清楚地知道 "The ones" 指的是参数。
与此类似，许多为 LDP 写作的作者使用笑脸和感叹号，而这些在正式文档或语法手册中是永远不会被接受的。目前要遵循的一般规则是保留笑脸和不必要的标点符号，除非它们干扰读者对所解释概念的理解。这背后的理由是为了保护 LDP 文档更具对话性的语气。
大写字母的使用。单词 "HOWTO" 应始终全部大写，且不带连字符。文档的标题和章节标题可以遵循两种约定之一，但必须保持一致。标题可以仅将第一个单词大写，也可以将每个单词都大写。在第二种情况下，标题中唯一不应大写的单词是介词、冠词和在其他情况下也不会大写的专有名词（例如：insmod）。其他大写应遵循标准英语规则。
清晰度。 对清晰度的判断有时很难做出。评估清晰度的一个成功策略是问这个问题：“如果我还不了解这些信息，从本文档中解释是否清楚？” 如果您已经大致了解作者想要表达的内容，但仍然感到困惑，那么很有可能对于第一次阅读该文档的人来说，解释确实令人困惑。如果您遇到这种情况，并且您真的不知道如何纠正技术解释，或者您担心您的更改可能会影响文档的含义，请向技术专家寻求帮助。如果没有技术专家可用或没有人回应您的请求，请在审核中注明需要的更改，并标记这些问题需要在技术审核中解决。
组织。 在某些情况下，文档确实可以从不同的结构中受益。当这些问题干扰对文档中信息的理解时，您应该解决这些问题。如果文档在执行过程之后才提供背景信息，那么对于读者充分考虑在执行任务之前需要的信息来说，这可能为时已晚。寻找可能使读者感到困惑或误导的文档组织方式。这些将是您想要解决的问题类型。一旦确定了这些问题，最好让作者知道您的理由，并与他或她讨论重大更改。
句子结构。 在某种程度上，句子结构问题在语法部分中已经讨论过；但是，还有一些额外的问题在语法上没有错误，但确实会干扰读者对材料的理解。其中最明显的之一是堆叠的介词短语。当文档的可读性受到影响时，堆叠的介词短语就会成为问题，因为它越来越不清楚句子的主语和动作是什么。在某些情况下，需要更精确的描述符，或者需要将一个难以理解的长句子更改为两到三个更容易阅读的句子。
可读性。 这个领域有些主观。对于一个人来说相当可读的材料对于另一个人来说可能令人困惑。因为这是一个价值判断，所以在标记作者关于可读性的作品时，您应该谨慎。在基于可读性进行判断时，要意识到您可能正在处理风格偏好。在 LDP 的这个阶段，没有作者需要遵循的既定风格或文体规则。在评估可读性时，您必须考虑文档的写作方式是否真的会干扰读者对信息的理解。如果您得出的答案是 “不，但这听起来不像我认为应该的那样。”，那么您可能不应该重写文本以使其听起来更符合您的想法。
标题。标题应采用正确的标题大小写格式。此格式的一般原则是标题中除介词和冠词外的所有单词都大写（如果冠词是标题中的第一个单词，则应大写）。单词 HOWTO 应全部大写。单词 HOWTO 中不应有连字符。版本号不应包含在标题中。
日期格式。日期应采用标准 ISO 格式，即 YYYY-MM-DD。
术语的统一使用。 因为您正在审核的 HOWTO 可能充满了读者的新信息，所以文档中讨论的术语保持统一非常重要。例如，在文档的某一部分中用一个名称指代某个部件或参数，然后在文档的另一部分中用另一个名称（或尚未解释的缩写）称呼它，这对读者来说是令人困惑的。确保术语在整个文档中保持一致对于帮助读者理解文档有很大帮助。
首字母缩略词或俚语的定义。 计算机技术领域的术语和语言变化迅速。在审核文档时，您可能会发现正在讨论的许多术语在您熟悉的任何字典或技术参考中都不是有效的单词。在这种情况下，您需要搜索这些术语，并确定它们是否实际上是 Linux 社区普遍接受的术语。不太熟悉的术语应在首次出现后立即定义。如果俚语会导致读者对术语的内涵或外延感到困惑，则应将俚语替换为更常用的术语。请记住，使用该文档的读者可能并非以英语为母语，因此，您应尽力确保该文档尽可能易于理解。
拉丁语缩写。避免使用缩写。例如，e.g.（例如）、et al.（等等）、etc（等等）和 i.e.（即）应始终使用英语等价物。