Help:系统消息

注意：当您编辑本页面时，即同意以CC0协议授权您的贡献。您可以在公有领域帮助页面找到更多信息。

系统消息是纯文本、wiki语法、CSS或JavaScript代码片段，可以用来自定义页面和每种语言的外观和行为和区域设置。 MediaWiki使用消息的任何面向用户界面的一部分，用于核心和扩展的MediaWiki UI的国际化和本地化。 MediaWiki中使用的所有消息都在 消息文件 中。

您可以通过在wiki上编辑消息来覆盖消息的默认值。 每条消息在MediaWiki命名空间中都有一个wiki页面，其消息键作为页面的名称。 例如，“aboutsite”消息存储在MediaWiki:aboutsite中。 默认情况下，除非用户具有“editinterface”权限，否则此命名空间将被禁止编辑。 可以在Special:AllMessages上找到所有消息页面的列表。 编辑界面消息通常很简单，就像编辑普通的wiki页面一样，但它仅限于具有editinterface权限的用户，默认情况下这个权限会分配给管理员（和界面管理员）。

Special:AllMessages表包含两列：链接的接口名称和文本。 文本水平分割以显示上面的默认文本，以及下面的自定义文本。 如果自定义消息不存在，则仅显示默认消息。 要自定义消息，请单击左列中的上部链接（消息名称）。 如果正在使用默认文本，则此链接为红色，因为编辑页面为空。

左列单元格中的下部链接指向该消息的讨论页面。

只有在以下情况下，才建议覆盖维基上的消息：

• 这条消息有一个严重的错误，必须尽快纠正。 在这种情况下，如果是英文的，建议在源代码中也修复这个错误，如果不是，建议在维基翻译网上的翻译中修复这个错误。 在部署更正时，应该删除具有本地自定义的页面。
• 如果本地维基使用不同的术语。 例如，很多信息使用“页面（page）”一词，但英文维基百科经常使用“文章（article）”。
• 本地消息正在尝试添加一些独特的功能，例如用于小工具或模板。 （在这种情况下，仍然建议考虑更改源消息或将此功能封装在扩展中，以便其他Wiki能够方便地使用它，而不必手动复制定制。）

根据消息文档指南，MediaWiki如何使用每条消息，可用的变量，使用的参数，限制等等可以在qqq伪语言的完整文档中找到解释。 对于旧版分类:界面消息 中的某些接口消息，可能存在一些较长的解释页面。

在MediaWiki 1.18及以上版本中，您可以通過瀏覽維基中的特殊偽語言代碼qqx，這可以透過附加?uselang=qqx到URL後面或者附加&uselang=qqx，如果URL已经存在?字元（示例），来查看一个页面的系统消息鍵。 所有引用自系统消息的内容都会被一个key代替，告诉你这个内容来自哪一个系统消息。 使用内容语言显示的消息不会使用qqx显示。

如果页面使用例如标签，例如 特殊页面设置，你必须在uselang参数后面添加标签，例如Special:Preferences?uselang=qqx#mw-prefsection-rendering。

在MediaWiki 1.38版本之前，回退消息键不会显示，这使得识别某些消息来源变得困难，尤其是页面导航标签。自MediaWiki 1.38起，回退消息键会以斜杠分隔显示（$2）。 Since MediaWiki 1.38 fallback message keys are shown separated by slashes (/).

在MediaWiki 1.43版本之前，被覆盖的消息键（通过如MessageCacheFetchOverrides 的钩子实现）同样不会显示，这使得难以识别由扩展程序（例如WikimediaMessages ）覆盖的消息来源。自MediaWiki 1.43起，被覆盖的消息键将在等号（$3）后显示。 Since MediaWiki 1.43 override message key is shown after an equals sign (=).

MediaWiki中使用的所有消息都在 消息文件(MediaWiki命名空间) 中定义。

MediaWiki中有两种类型的消息文件：JSON和PHP。 截至2014年4月，核心MediaWiki和大多数维护的扩展已迁移到JSON格式。 您应该将JSON用于所有新开发。 有关迁移到JSON的更多信息，请参见 Requests for comment/Localisation format

从2013年底开始，引入了一种新的消息文件格式：JSON。 JSON，非常常见的数据存数格式。 其中的每个键都是消息键，值是消息文本。 此外，特殊的 @metadata 键用于存储有关翻译的信息，如翻译作者。

使用JSON使本地化文件更安全，因为它是不可执行的（JSON是纯文本）。 它还与jquery.i18n兼容，jquery.i18n是作为Project Milkshake的一部分开发的JavaScript库，它提供类似MediaWiki的前端本地化功能，并被一些希望减少对MediaWiki的依赖的扩展使用，如可视化编辑器和语言选择器。

由于更广泛的国际化和本地化工具被称为“Project Milkshake”，一些人将这种形式称为“香蕉”。

在MediaWiki核心中，本地化文件放在languages/i18n目录中。 MediaWiki扩展通常将它们的扩展放在i18n/的子目录中。 如果一个项目中存在大量消息，为了便于维护，可能需要将这些消息拆分到两个或多个主题子目录中。 如果一个项目中存在大量消息，为了便于维护，可能需要将这些消息拆分到两个或多个主题子目录中。 以下是MediaWiki的 VisualEditor 扩展的一个例子：

{
  "MessagesDirs": {
    "VisualEditor": [
      "lib/ve/modules/ve/i18n",
      "modules/ve-mw/i18n",
      "modules/ve-wmf/i18n",
      "lib/ve/lib/oojs-ui/i18n"
    ]
  }
}

您可以将新消息添加到英文“en”消息文件en.json，并使用特殊的伪语言代码“qqq”– qqq.json将它们记录在消息��档文件中。 请看: 添加新消息.

目前，文件中使用以下元数据字段：

authors

消息作者的JSON列表。 对于英文(en)和消息文档(qqq)，这些是在编辑消息文件时手动添加的。 对于所有其他语言，从translatewiki.net中导出消息文件时会自动插入此选项。 可以在translatewiki.net上编辑消息文档，文档编辑器也会自动插入到qqq.json文件中。

message-documentation

这是用于存储消息文档的伪语言代码。 对于MediaWiki，这始终是qqq。 (这出现在一些扩展中，但实际上没有以任何方式进行处理。

这不是强制性的。)

转义诸如换行符之类的特殊字符("\n")。

用不同字母表示字母的Unicode字符被存储为实际字符，而不是字符代码，因为这些文件有时会被人们读取，而且这会使文件变小("誼"而不是"\u8ABC")。 在任何情况下，开发人员几乎没有理由编辑除英语以外的任何语言的消息，因为这些消息通常是通过translatewiki.net编辑的。

HTML代码也没有转义，因此是"<strong>Warning</strong>"而不是"\u003cstrong\u003eWarning\u003c/strong\u003e"。

JSON文件使用制表符进行缩进。

较早的本地化文件格式是PHP。 这实质上是一个包含所有消息的PHP数组。 在核心MediaWiki中，每种语言都驻留在MediaWiki源代码的languages/message目录中的自己的文件中。 在扩展中，所有语言和消息文档(qqq)都在同一个文件中：ExtensionName.i18n.php，通常位于扩展的主目录中。

要将系统消息从PHP迁移到JSON，请使用generateJsonI18n.php 脚本。 它会将消息移动到JSON文件，并用指向JSON文件的填充程序替换PHP文件的文本。 此样板代码是向后兼容MediaWiki 1.19所必需的。 它不用于不需要MediaWiki 1.19兼容性的新扩展中。

MediaWiki使用由代码中的键引用的消息的中央存储库。 这不同于例如gettext系统，后者从源文件中提取可翻译的字符串。 基于密钥的系统让一些事情变得更容易，比如提炼原始文本和跟踪消息的更改。 缺点是使用的消息列表和这些键的源文本列表可能不同步。 在实践中，这不是一个大问题，唯一重要的问题是，有时不再使用的额外消息仍在等待翻译。

要使消息键更易于管理和搜索，请始终完整地编写它们，不要太依赖于动态创建它们。 如果你觉得能给你的代码带来更好的结构，你可以把消息键的几个部分连接起来--但只有在肯定有多种可能性的情况下才这么做，^[1]，并且确保在旁边放上注释和可能产生的键的列表。 例子如下：

// 可在此处使用的消息：
// * myextension-connection-success
// * myextension-connection-warning
// * myextension-connection-error
$text = wfMessage( 'myextension-connection-' . $status )->parse();

另请参阅动态标识符编码约定。

要在JavaScript中使用消息，您必须在您的ResourceLoader模块的定义中的"messages"属性中列出他。

有关在PHP和JavaScript中使用消息函数的详细信息，请参阅Manual:系统消息API 。 这是一个重要的文档页，您应该在编写使用消息的代码之前阅读它。

代码从以下来源查找系统消息：

• MediaWiki命名空间 这允许维基在标准消息不适合或不需要时采用或覆盖其所有消息。
  • MediaWiki:消息名 是默认的消息存储位置
  • MediaWiki：消息名/语言名是当用户选择了维基默认语言以外的语言时使用的消息。
• 来自消息文件：
  • 核心MediaWiki本身和大多数当前维护的扩展名按语言使用一个文件，名为zyx.json，其中zyx是该语言的语言代码。
  • 一些较旧的扩展使用一个组合的消息文件来保存所有语言的所有消息，通常命名为MyExtensionName.i18n.php。
  • 许多Wikimedia Foundation维基访问来自维基媒体消息 扩展的一些消息，允许他们标准化WMF维基中的消息，而无需将它们强加给每个MediaWiki安装。
  • 一些扩展使用其他技术。

系统消息是MediaWiki较重要的组件之一，主要是因为它用于每个Web请求。 PHP消息文件很大，因为它们存储了数千个消息键和值。 加载该文件(如果用户的语言与内容语言不同，还可能加载多个文件)具有很大的内存和性能成本。 一个积极的、分层的缓存系统被用来降低这种性能影响。

MediaWiki内置了许多缓存机制，这使得代码更难理解。 从1.16开始，有了一个新的缓存系统，它将消息缓存到cdb文件或数据库中。 根据配置的不同，自定义消息會被缓存在文件系统和memcached（或备选）中。

下表概述了所涉及的设置：

在MediaWiki 1.27.0和1.27.1中，自动检测已更改为有利于文件后端。 在'store' => 'detect'(默认)的情况下，文件后端与从$wgCacheDirectory 开始的路径一起使用。 如果未设置此值(这是默认设置)，则使用由操作系统确定的临时目录。 如果无法检测到临时目录，则使用数据库后端作为备援。 由于共享主机上的文件冲突和安全问题(请参见T127127和T161453)，已从1.27.2和1.28.0恢复。

为了更好地直观地描述缓存层，这里有一个函数回溯，说明在检索消息时调用了哪些方法。 有关每一层的说明，请参阅以下各节。

• Message::fetchMessage()
• MessageCache::get()
• Language::getMessage()
• LocalisationCache::getSubitem()
• LCStore::get()

MessageCache类是消息的顶级缓存。 它从Message类中调用，并返回消息的最终原始内容。 该层处理以下逻辑：

• 正在检查数据库中的消息覆盖
• 在memcached 或设置为$wgMessageCacheType 的任何位置缓存被覆盖的消息
• 正在解析备援语言序列的剩余部分

最后一颗子弹很重要。 后被语言如果原始文档没有请求消息，则允许MediaWiki退回到另一种语言。 如下一节所述，大多数语言回退解析都发生在较低级别。 但是，只有MessageCache层检查数据库中是否有被覆盖的消息。 因此，这里完成了将被覆盖的消息从数据库集成到回退链中。 如果不使用数据库，则可以禁用整个层。

请参阅LocalisationCache.php

LCStore类只是LocalisationCache类用于实际缓存和检索消息的后端实现。 与在MediaWiki中用于通用缓存的BagOStuff类类似，有许多不同的缓存类型(使用$wgLocalisationCacheConf 配置)：

• db （默认）— 在数据库中缓存消息
• file （如果设置了$wgCacheDirectory，则为默认值）— 使用cdb将消息缓存到本地文件中
• accel – 使用APC或其他操作码缓存来存储数据

file选项由维基媒体基金会使用，之所以推荐它，是因为它比访问数据库更快、比APC缓存更可靠，特别是因为APC与PHP 5.5版或更高版本並不兼容。

参阅： Manual:代码编写约定

消息密钥必须是全局唯一的。 这包括核心MediaWiki以及所有的扩展和皮肤。

在消息名称中坚持小写字母、数字和下划线；大多数其他字符不太实用或根本不起作用。 根据MediaWiki约定，第一个字符不区分大小写，其他字符区分大小写。

请遵循全球或本地的命名约定。 对于扩展名稱，请使用标准前缀，最好是后跟连字符(-)的小写扩展名稱。 例外情况包括：

消息使用系统API

它们必须以apihelp-、apiwarn-、apierror-开头。 在此前缀之后加上扩展前缀。 (请注意，这些消息应该位于单独的文件中，通常位于includes/i18/api下。)

日志相关消息

它们必须以logentry-、log-name-、log-description开头。

用户访问权限

Special:ListGroupRights上显示的权限名称键必须以right-开头。 完成句子“因为以下原因，您没有权限$2：”的操作的名称必须以action-开头。

自定义的标签（详情参见Special:Tags）

自定义的标签必须使用前缀tag-。

特殊页面标题

特殊页面标题必须使用前缀special-。

擴充功能描述

擴充功能描述必須以擴充功能名稱開頭、以-desc結尾。

它們出現在表中的Special:Version處，其內容必須簡要說明該擴充功能是在做什麼。

英文訊息幾乎不需要根據使用者的性別而改變用詞。 英語只需要在第三人稱代詞（「他」和「她」）中使用，但這些代詞在訊息中卻驚人地少見。 在必要時，請使用{{GENDER:$1|he|she|they}}。

然而，許多其他語言需要根據使用者的性別使用不同的詞彙，不僅限於第三人稱代詞，還包括其他代詞，以及不同時態的動詞（例如「創建」、「刪除」）、名詞（例如「導師」、「管理員」）、形容詞（例如「新的」）等。 因此，即使只有一個英文單詞，在英文訊息中使用GENDER也往往很有用。 這給翻譯人員提供了一個提示，即GENDER可以用於信息中。 它還避免了在可選的用戶名參數缺失時，translatewiki 上出現關於缺失參數的警告（這種情況在日誌條目訊息中尤為常見）。

1. 确保您对消息使用了适当的处理(解析、{{替换、转义为HTML等)。
2. 如果您的消息是核心的一部份，则通常应该将其添加到languages/i18n/en.json，尽管有某些特殊的组件(例如Installer、EXIF标记、ApiHelp、偏好設定、以及其他的)有它们自己的消息文件。
3. 如果您的消息是扩展名，请将其添加到相应子目录中的i18n/en.json文件或en.json文件中。 特别是，只有开发人员才能看到而大多数最终用户不能看到的API消息通常位于单独的文件中，如i18n/api/en.json。 如果扩展名有很多消息，您可以在i18n下创建子目录。 所有消息目录，包括默认的i18n/，必须在extension.json的MessagesDirs部分或$wgMessagesDirs 变量中列出。
4. 暂停一下，考虑一下这条信息的措辞。 是不是越清楚越好？ 它会被误解吗？如果可能的话，征求其他开发人员或本地化人员的意见。 遵循国际化提示。
5. 将文档添加到同一目录中的qqq.json。
6. 請勿随意按字母顺序对消息进行分类。 文件中消息的顺序应该大致符合项目的特点。 将来自同一功能的消息放在一起。 这有助于翻译人员保��专注、高效和一致。
7. 若某条消息或其文档（qqq）引用了同一JSON文件中的另一条消息，请尽量将此消息置于被引用消息之后，以便译者在翻译引用消息之前，有机会先翻译被引用的消息。 这并非总能实现，例如当信息相互关联时，但请在可能的情况下尽力而为。 （引用通常通过在消息本身中使用{{int:键}}魔术字或在qqq文档中使用{{msg-mw}}模板来完成。详见消息文档部分。）
8. 将预计最基本和最频繁使用的消息放在文件的开头，将较罕见和技术更先进的消息放在文件末尾。

1. “已屏蔽”消息是那些应该只以英文存在的消息消息文件。 它们是不需要翻译的消息，因为它们只引用其他消息或语言无关的功能，例如。

一条“{{SITENAME}}”的消息。

1. 只有在以目标语言更改的情况下，才能翻译“可选”消息。

To flag such messages:

• 分别使用qqq报文文档中的模板
  1. {{notranslate}} 或者
  2. {{optional}};
• 通过提交相应的补丁程序，告知translatewiki.net 上使用的Translate（翻译） 扩展如何处理这些消息(另请参阅完整配置文档 )：
  • 对于核心，在groups/MediaWiki/MediaWiki.yaml中添加消息密钥
    1. 在ignored:项下或
    2. 在optional:项下;
  • 对于扩展，在groups/MediaWiki/mediawiki-extensions.txt中，在扩展名下添加一行，如下所示
    1. ignored = msg-key-1,msg-key-2 or
    2. optional = msg-key-1,msg-key-2.

从en.json和qqq.json中删除它。 不要费心学习其他语言。 从translatewiki.net 开始的更新将自动处理这些更新。

此外，检查消息是否出现在转换维基配置中的任何位置，例如，在可选或最常用的消息列表中(一个简单的git grep就足够了)。 如果需要，请将其从这些列表中删除。

1. 考虑更新消息文档。
2. 如果旧的翻译不适合新的含义，请更改消息键。 这还包括消息处理(解析、转义、参数等)的更改。 在没有技术更改的情况下改进消息的措辞通常不是更改密钥的理由。 在translatewiki.net上，这些翻译将被标记为过时，以便翻译人员可以针对它们。 更改消息密钥不需要与I18N团队交谈或提交支持请求。 但是，如果您有特殊情况或问题，请询问#translatewiki ^在线或在支持页面中询问translatewiki.net 。
3. 如果translatewiki.net 支持扩展，请仅更改英文源消息和/或密钥，以及qqq.json中的附带条目。 如有需要，translatewiki.net团队将负责更新翻译、标记过时内容、清理文件或在可能情况下重命名键值。 这也适用于你仅修改如HTML标签这类内容的情况，即便不懂其他语言，你也能进行此类更改。 这些操作大多将在translatewiki.net上进行，并会延迟约一天后同步至Git。

有一个用于记录信息的伪语言代码qqq。 它是ISO 639专用代码之一。 在那里，我们不保留每条信息的译文，而是收集关于每条信息 的英文句子：告诉我们它在哪里被使用，提示我们如何翻译它，列举并描述它的参数、相关信息的链接等。 在translatewiki.net，这些提示会在译员编辑信息时显示。

程序员必须记录每一条信息。 消息文档是一项重要资源——不仅对于翻译人员，而且对于模块的所有维护人员都是如此。 每当在软件中添加一条信息时，必须同时添加相应的qqq条目；没有这样做的修订版会被标记为“V-1”，直到文档添加完毕。

只有在添加新信息或更改现有英文信息时才可以直接编辑qqq文件中的文档，例如添加或删除参数。 其他情况下，通常应在translatewiki中编辑文档。 每个文档字符串都可以在https://translatewiki.net/wiki/MediaWiki:message-key/qqq中访问，就像翻译一样。 这些编辑将与翻译一起导出到源代码库。

文件中应包含的有用信息包括：

1. 信息处理（解析、转义、纯文本）。
2. 参数类型及示例值。
3. 信息的使用位置（页面、用户界面中的位置）。
4. 信息在使用处如何使用（页面标题、按钮文本等）。
5. 与此信息一同使用的其他信息，或此信息指向的其他信息。
6. 其他任何在上下文中看到信息时可以理解，但在单独显示信息时无法理解的内容（翻译时就是这种情况）。
7. 语法的注意事项，如果存在。 例如，英语中的“open”既可以是动词，也可以是形容词。 在许多其他语言中，单词是不同的，没有文献资料是无法猜测如何翻译的。
8. 描述事物的形容词，如“disabled”、“open”或“blocked”，必须总是说明它们描述的是什么。 在许多语言中，形容词的性别必须与所描述的名词一致。 不同种类的事物也可能需要不同的形容词。
9. 如果信息具有特殊属性，例如，它是否是一个页面名称，或者它是否不应该直译，而应该根据文化或项目进行调整。
10. 信息是否出现在其他信息附近，例如在列表或菜单中。 措辞或语法特征可能应与附近的信息相似。 此外，列表中的项目可能必须与列表标题适当关联。
11. 信息中不得翻译的部分，如通用命名空间名称、URL或标签。
12. 对可能不清楚的词语的解释，例如缩写词，如“CTA”，或特定术语，如“templat”、"suppress "或 "stub"。 （注意最好首先避免使用此类词语！）。
13. 截图很有用。 不要裁剪——显示信息的全屏图像可提供完整的上下文，并可在多条信息中重复使用。

一些其他提示：

• 请记住，很多时候翻译人员翻译信息时并没有真正使用那个软件。
• 通常情况下，翻译人员没有任何上下文信息，既不知道您的模块，也不知道模块中的其他信息。
• 在大多数情况下，仅靠重新措辞的信息是没有用的。
• 不要使用设计师的专业术语，如“hamburger”、“nav”，或“comps”。
• 考虑编写术语表，介绍模块中使用的专业术语。 如果你这样做了，请将信息文档链接到它。
• 信息文档在translatewiki上以wikitext形式展示并解析。 若需使用wikitext或HTML标签并希望其原样显示而非被解析，请使用‎<nowiki>。

您可以使用{{msg-mw|message key}}链接到其他信息。 如果部分信息来自其他信息（如果无法避免），或者某些信息一起显示或在同一上下文中显示，请这样做。

translatewiki.net提供了一些默认的文档模板，應該用於文檔中，例如：

{{doc-action|[...]}}

用于action-消息

{{doc-right|[...]}}

用于right-消息

{{doc-group|[...]|[...]}}

用于用户组相关（group, member, page, js和css）的消息

{{doc-accesskey|[...]}}

用于accesskey-消息

{{doc-api*|[...]}}

API 帮助和 API 錯誤訊息的模板集

{{doc-api*|[...]}}

一套用于API帮助和API错误信息的模板

{{experimental}}

用于标记近期可能变更信息的模板（请记住在信息稳定后将其移除）

{{logentry}}

标记日志消息的模板

{{optional}}

一个用于标记可选消息的模板，这些消息不应翻译成大多数语言，且默认不向翻译者显示。

{{ignored}}

标记忽略信息的模板，此内容绝不可翻译。

{{doc-important}}

文档中用于强调段落的模板。

更多此類模板可參見Message Documentation Templates類別。 去看看模板页面以了解更多信息。

除了文档之外，翻译人员还希望开发者能考虑一些建议，以便让他们的工作更轻松高效，并确保所有语言都能实现真实且优质的本地化。 即使只是添加或编辑英文信息，也应考虑到所有语言的需求。 每条信息都被翻译成超过300种语言，且应尽可能以最佳方式完成。 正确实施这些提示往往也能帮助您用英语写出更好的信息。

Localisation#Help and contact info列出了您可以寻求有关国际化方面经验丰富人士帮助的主要渠道。

这是确保你信息措辞准确的前提条件。

译者不鼓励复用信息。 这或许有悖常理，因为复制和重复代码通常被视为不良实践，但在系统消息中却常常是必要的。 尽管两个概念在英语中可以用同一个词表达，但这并不意味着在所有语言中都能用同一个词表达。 "OK"就是一个很好的例子：在英语中，它常用作通用按钮标签，但在某些语言中，人们更倾向于使用与按钮将要执行的操作相关的标签。 另一个例子是几乎所有的形容词：在许多语言中，像“multiple”这样的词会根据性别变化，因此你无法重复使用它来描述几种不同的事物，而必须创建多个独立的信息。

若需添加多条相同信息，请附上信息说明以阐述其在不同上下文中的差异。 别担心翻译人员额外的工作量。 在这些情况下，翻译记忆库大有裨益，同时保留了必要时采用不同译文的灵活性。

语言拥有不同的语序，以及复杂的语法和句法规则。 由多段文本构成，可能带有间接引用，在代码中无法由翻译者直接控制的信息，在开发者的行话里被称为“乐高”或“拼凑”信息。实际上，正确翻译“乐高”信息几乎是不可能的。

让每条信息都成为完整的句子。 如有需要，多个句子通常可以更容易地组合成一个文本块。 当你想在一条信息中组合多个字符串时，请将它们作为参数传入，这样翻译者在翻译时能根据各自语言的语法正确排序。

规则的一个例外可能是相互引用的信息：“在标有{{int:name}}的字段中输入原作者姓名，完成后点击{{int:proceed}}”。 这使得当软件开发者或wiki操作者稍后更改消息的“名称”或“继续”时，信息能够保持一致。 没有int技巧，开发者和操作员在修改一条消息时，必须意识到所有需要调整的相关信息。

尽可能使用自然、人性化的语言撰写信息。 试着大声读出这条信息并思考：这听起来像是人类会“说”的正确、符合语法的英语吗？ 如果它在英语中显得复杂、拗口或任何形式的不自然，那么对于译者和其他语言的用户来说，处理起来只会更加困难。

避免使用过于技术化、官僚化或难以朗读的标点符号。 斜杠（/）通常应替换为“or”。 And/or 应替换为“and”或“or”。 带��逗号拼接的句子应拆分为较短的句子。

MediaWiki被形形色色的人们所使用，无论是在维基媒体运动内部还是外部。 尽管最初是为百科全书而建，如今它已用于承载各类内容。 因此，请使用通用术语。 例如，避免使用“article”这类术语，除非你完全确定所开发的功能仅适用于将页面称为“article”的网站，否则请用“page”代替。 不要使用“village pump”，这是英文维基百科社区页面的名称，请使用通用术语，例如“community discussion page”。

不要假定所有wiki上都存在某个模板。 模板是各个wiki本地化的。 这适用于源消息及其翻译。 如果消息使用模板，那么只有在部署该功能的每个wiki上都创建了模板，它们才能正常工作。 在信息中最好完全避免使用模板。 若确实需要使用它们，则必须在消息文档及扩展安装说明中明确记录这一点。

某些语言在日期与时间之间需插入语法上依赖于句中其他词汇的成分。 因此，他们将无法同时使用日期和时间。 他人或许会觉得这种组合方式很方便，因此在类似情况下，通常最佳的做法是提供三个参数值（日期/时间、日期、时间），并在每次翻译中根据需要，要么忽略第一个参数，要么忽略后两个参数。

{{SITENAME}}有几个缺点。 它可以是任何東西（首字母縮寫、單詞、短語、“等等”等），根據語言的不同，可能需要在每次出現時使用 {{GRAMMAR}} 。 無論如何，在大多數維基語言中，每個具有{{SITENAME}}的訊息都需要在安裝有您的代碼的每個新維基上進行審查。 在大多数情况下，如果某種語言沒有通用的 GRAMMAR 配置，維基運營商將需要添加或修改 PHP 代碼，以使 {{GRAMMAR}} 對應 {{SITENAME}} 正常工作。 這需要更多的技能、和更多的理解力，甚於其他的情況。 使用像“本wiki”这样的通用引用更方便。 这并不妨碍安装程序在本地修改这些信息以使用{{SITENAME}}，但至少他们不必这样做，而且可以将信息适配工作推迟到wiki已经运行并被使用之后。

渲染内容的位置取决于皮肤。 通常，从左至右书写语言的屏幕布局会与从右至左书写语言的布局呈镜像对称，但这并非绝对，对于某些语言和维基而言，这种镜像关系并不完全一致。 手持设备、窄窗口等可能会将较大屏幕上并排显示的区块改为上下排列。 由于站点和用户编写的JavaScript脚本与小工具能够以不可预测的方式隐藏部分内容或移动元素，因此无法可靠地获知实际布局。

将布局信息与内容语言绑定是错误的做法，因为用户界面语言可能与页面内容语言不同，且布局往往需要根据实际情况混合使用两种语言。 像声学屏幕阅读器这样的非视觉用户代理以及其他辅助设备甚至没有视觉布局的概念。 因此，在大多数情况下不应参考视觉布局位置，但语义布局术语仍可使用（例如“表单中的前几步”等）。

MediaWiki不支持根据当前界面方向性显示不同的消息或消息片段（参见T30997）。

即将到来的浏览器和MediaWiki对东亚及北亚自上而下书写方式的支持，将使屏幕布局变得更加难以预测，至少存在八种可能的布局方式（起始位置左/右、起始位置上/下，以及两者发生的先后顺序）。

物体呈现的颜色取决于多种因素，包括皮肤、网站及用户编写的JavaScript脚本和小工具，以及出于无障碍访问或技术限制考虑而进行的本地用户代理覆盖设置。 像声学屏幕阅读器这样的非视觉用户代理以及其他辅助设备甚至没有颜色的概念。 因此，你不应该参考屏幕颜色。 （出于同样原因，也不应仅依赖颜色作为向用户传达状态的机制。）

无需翻译的HTML标记，例如包含‎<div>标签、上下方的标尺等类似内容，通常不应包含在消息中。 这对译者来说是不必要的负担，且在翻译过程中常常被无意修改或遗漏。 翻译界面缺乏语法高亮和有限验证功能，因此错误频发。

避免复杂的wikitext标记。 wikitext有时比用PHP编写相同内容更为简洁，因此人们常常倾向于写出类似这样的代码：

This is the [[{{MediaWiki:Validationpage}}|stable version]], [{{fullurl:{{#Special:Log}}|type=review&page={{FULLPAGENAMEE}}}} checked] on <i>$2</i>.
[{{fullurl:{{FULLPAGENAMEE}}|oldid=$1&diff=cur}} $3 pending {{PLURAL:$3|change|changes}}] {{PLURAL:$3|awaits|await}} review.

然而这对译者来说颇为棘手，尤其是在翻译为从右至左书写的语言时，因为部分信息必须保留英文原样，导致单行文本中文字方向需多次切换。

هذه هي [[{{MediaWiki:Validationpage}}|النسخة المستقرة]]، [{{fullurl:{{#Special:Log}}|type=review&page={{FULLPAGENAMEE}}}} المفحوصة] في <i>$2</i>.
[{{fullurl:{{FULLPAGENAMEE}}|oldid=$1&diff=cur}} {{PLURAL:$3||تغيير واحد معلق|تغييران معلقان|$3 تغييرات معلقة|$3 تغييرا معلقا|$3 تغيير معلق}}] {{PLURAL:$3||ينتظر|ينتظران|تنتظر|ينتظر}} المراجعة.

最好将任何链接目标作为消息参数传递，并仅使用像[$1 标签]和[[$1|Label]]这样的简单标记。

不要在消息中使用formatnum 魔术字 。 按照Manual:系统消息API 中的指示，格式化加载消息代码中的数字参数。

浏览外语信息文件时，几乎找不到比中文译文更短的翻译，也很少见到比英文原文更简短的版本。然而，常常会发现译文远比英文原文冗长。

尤其在表单中，输入框前的英文提示往往简洁而简短。 这在翻译中常常未能保留。 某些语言可能缺乏英语中的技术词汇，解释某些概念时可能需要多个词汇甚至完整的句子。 例如，简短的英文信息"TSV file:"可能需要按字面意思翻译成某种语言。

请在此处输入一个名称，用以指代一种由按顺序组织的打印行构成的计算机数据集合，其中每一行又由多个信息字段组成，这些字段之间以特定符号分隔——该符号能驱动打字机滑架前进至下一个预设位置。开始输入：_____（感谢）

诚然，这是一个极端的例子，但你可以从中窥见其特点。 想象这句话在表格的一列中，每个单词独占一行，而输入框则在下一列垂直居中。 :-(

例如，页面可能包含较旧的“修订”（特定日期、时间和编辑），这些修订构成了该页面的过往“版本”。 “修订”（revision）和“版本”（version）这两个词可以互换使用。 因而产生了问题，即当版本页面被修订时，修订过程本身也被提及。 当"revision"的两个同义词有不同的翻译时，这可能不会构成严重问题。 然而，切勿依赖于此。 因此，最好完全避免使用“修订”即“版本”这一说法，以防产生误解。

有些词语因其在MediaWiki中的特定用途而难以翻译。 有些可能完全不被翻译。 例如，在多种语言中并没有与“使用某物的人”相关的“用户”一词。 同样在科隆语中，英语单词“namespace”和“apartment”翻译成同一个词汇。 在科隆方言中，他们用一个词表达“佐证者与参与者”，因为任何提及“使用”都会过于强烈地暗示“滥用”。 "维基农场"一词被译为"充满维基的马厩"，因为在语言中，单一作物的农场在术语上会自相矛盾，且不易被理解，等等。

在讨论技术参数、数值或键盘输入时，请使用HTML标签‎<code>、‎<var>或‎<kbd>进行适当标记。 因此它们在排版上与普通文本有所区别。 这使读者能够清晰理解其含义，避免混淆、错误和曲解。 确保您的消息处理器支持此类标记。

许多符号同样具有本地化特性，一些文字系统拥有不同于拉丁字母的括号形式。 在某些语言中，标签或输入提示后使用冒号可能并不合适。 在信息中包含这些符号有助于生成更优质、更少以英语为中心的翻译，同时也能减少代码的混乱。

例如，«挪威语»、”瑞典语”、»丹麦语«、„德语”以及「日语」中使用的引号规范各不相同。^[2]

若需在本地化括号、方括号或引号中包裹文本，可参照如下方式使用parentheses （$1）、brackets [$1]或quotation-marks “$1”消息：

wfMessage( 'parentheses' )->rawParams( /* 括号内的文本 */ )->escaped()
wfMessage( 'brackets' )->rawParams( /* 方括号内的文本 */ )->escaped()
wfMessage( 'quotation-marks' )->rawParams( /* 放入引号内的文本 */ )->escaped()

从右向左书写的语言（不同于英语）通常会交换表示“下一页”和“上一页”链接的箭头符号，并且这些符号相对于消息文本的位置也可能随之颠倒。 省略号可以翻译为"等等"，或者用词语表达。 问号、感叹号、冒号将出现在句子中间，而非句末，或者完全不出现，甚至重复出现。 因此，务必在消息文本中包含所有这些内容，切勿尝试以编程方式插入它们。

正常句子请务必以句号结尾。 这通常是译者区分其与标题或列表项的唯一依据，后者可能需要不同的翻译处理。

确保锚点能准确描述目标页面。 始终避免使用常见且泛泛的词语。 例如，“点击这里”是绝对不可取的，^[3]因为目标页面几乎从不涉及“点击这里”。 相反，应使用精确的动作词汇，告知用户点击链接后将获得什么，例如“如您愿意，可以上传文件。”

另请参阅“帮助用户预测其去向”、神秘肉导航以及“我们不应使用‘点击此处’作为链接文本的主要原因”。

在信息中避免使用开发者和高级用户的专业术语，尽可能使用简单易懂的语言。 在通知用户某事件发生或未发生时，避免使用“成功”、“成功地”、“失败”、“在...时发生错误”等表述。 这源于开发者习惯以是非对错看待一切，而用户通常只想知道实际发生了什么、未发生什么，以及他们应当如何应对（如果需要的话）。因此：

• “文件已成功重命名”->“文件已重命名”
• "文件重命名失败" -> "已存在同名文件，请选择其他名称。"

MediaWiki的本地化信息通常在wiki内部进行编辑，无论是通过实时wiki的wiki操作，还是由translatewiki.net上的翻译人员完成。 您应当注意消息中的空格，特别是开头或结尾处的空格，将如何影响编辑者：

• wikitext编辑器会自动移除消息末尾的空格和换行符。请确保您的消息不以空格或换行符结尾，因为在wiki上编辑时这些内容将会丢失。
• 开头处的空格和换行不会自动移除，但在编辑过程中很可能被无意删除，因此应当避免使用。

用活动文本开始和结束你的消息；如果需要在周围换行或分段，你的外围代码应负责将其添加到返回的文本中。

有些消息需要在末尾添加空格，例如word-separator（在大多数语言中仅由一个空格字符组成）。 为支持此类使用场景，即使消息通常不允许维基文本或HTML格式，以下HTML实体在消息中仍被允许并会转换为实际字符：^[4]

•   – 空格
•   或   – 不间断空格
• ­ – soft hyphen

与此相关的是，任何受预保存转换影响的其他语法元素也不得在消息中使用，因为这些元素在维基上编辑消息时会被转换。

大写形式为翻译者提供了关于翻译内容的线索，例如单个词汇、列表或菜单项、短语或完整句子。 正确（标准）的大小写也可能影响搜索引擎对您页面的评估。 MediaWiki在界面消息中采用句子大小写格式（The quick brown fox jumps over the lazy dog）。

永远记住，许多书写系统根本没有大写字母，而有些有大写字母的系统，其使用方式也与英语不同。 因此，不要用全大写来强调。 使用CSS，或HTML ‎<em> 或 ‎<strong> 如下所示：

在常规文本中，强调形式如粗体或斜体及其类似样式应作为消息文本的一部分。 关于强调的本地惯例常常各不相同，尤其是一些亚洲文字有其独特的规则。 译者必须能够根据目标语言和领域调整重点。 在您的用户界面中尝试使用‎<em>和‎<strong>，以便基于每种语言或每种文字进行标记。

在现代英文及欧式风格的屏幕布局中，强调手法的运用已逐渐减少。 请在您的#消息文档中传达它，因为它可能为如何翻译提供宝贵的线索。 只要译者了���其用法，重点强调可以在其他文化语境中适当使用，且应当如此。

It sometimes happens that English messages don't need some $ parameters or PLURAL or GENDER support, but translations of those messages into other languages do need them. In such cases, these parameters or keywords must be added to English, even if they don't do anything.

This is necessary for two reasons:

• It clearly shows the translator within the message that those parameters are available.
• It prevents translatewiki from showing warnings about parameters that are used in the translation, but aren't used in English.

For example, the English word "deleted" may refer to one deleted page or to several deleted pages, but in other languages the word would be different depending on the number of pages. So write something like this: {{PLURAL:$1|deleted}}.

• 自定义
• Manual:配置设置
• Manual:皮肤
• Manual:系统消息API
• 本地化
• 手册:MediaWiki架构与本地化信息
• translatewiki:FAQ