WordPress:Reporting Bugs

Every application has bugs -- as long as humans write code, there will continue to be errors in software. Some errors are trivial, while others are critical. Open-source projects like WordPress:WordPress need the participation of their user communities to identify bugs in their software, as well as to plan for new features.

每个应用软件都有程序错误—只要是人类在编写代码，软件不断地就会有程序错误。有的错误是轻微的，而有的错误确实致命的。开放源码软件，像WordPress需要WordPress的用户参与，识别软件中的程序错误，准备新的功能。

All types of feedback — whether they're genuine bugs or feature requests — are reported the same way in the WordPress project. Read on to learn how to report bugs and issues for WordPress... you may also want to read WordPress:Contributing to WordPress to find out how to contribute to the documentation and other areas of the WordPress project.

所有类型的feedback —不管是真正的程序错误还是功能请求—都是以同样的方式在WordPress软件中报告的。继续阅读，学习关于怎样报告程序错误和关于WordPress方面的问题… 你也可能想要阅读奉献于WordPress了解怎样对WordPress文档以及WordPress软件项目的其它领域做贡献。

报告安全问题

While we try to be proactive in preventing security problems, we do not assume they'll never come up. If you believe you've found a security problem in a release of WordPress please send mail to security at the WordPress.org domain and we'll do our best to address it as soon as possible.

虽然我们试着提前预防安全问题，我们并没有假定安全问题永远都不会出现。如果你相信在WordPress发行的某个版本中发现了安全问题，请发送电子邮件到WordPress.org domain的security，我们会尽快地解决这个问题。

It is standard practice to notify the vendor (the WordPress developers, in this case) of a security problem before publicizing so a fix can be prepared and public damage due to the vulnerability minimized.

先通知出售商（在这种情况是WordPress开发人员），关于安全方面的问题，再将WordPress发行，这样可以准备解决程序错误的方法，因为程序错误而导致的危害，也能够最小化。

在插件和主题中报告程序错误

If you find a bug in a Plugin or Theme you are using with WordPress, do NOT report it using the procedures in this article! Instructions in this article apply only to bugs in the WordPress core, and do not apply to bugs in plugins and themes.

如果你在WordPress插件或者主题中发现了程序错误，不要使用这篇文章所述的步骤，报告错误。这篇文章中报告程序错误的方法，只适用于WordPress核心，不适用于插件和主题。

Plugins which reside in the WordPress Plugin Repository have a separate bug tracking system from the WordPress core. Separate instructions are available for using that system.

WordPress 插件 资源库中的插件拥有来自WordPress核心的分开的程序错误追踪系统。可以使用Separate instructions来使用这个系统。

For plugins which do not reside in the official repository, and for themes, check the documentation that came with the plugin or theme for instructions on where to report bugs. If no bug reporting information came with your plugin or theme, you'll need to contact the author directly.

对于官方的插件资源库以外的插件和主题，查看插件或者主题的指示说明，了解怎样报告程序错误。如果你的插件或者主题没有关于报告程序错误的信息，你就需要直接地联系插件或者主题的作者。

程序错误报告和解决方法概述

There are several steps in the process of reporting and resolving a WordPress bug. Here is an overview; more details are in sections below.

关于报告和解决WordPress程序错误问题，有几个步骤。这里是概述；更多的详细信息，在下面的部分。

1. A user finds a bug that appears to be in the core of WordPress (not in a Theme or Plugin).

1. 用户在WordPress核心发现了一个程序错误（错误不是在主题或者插件中0

1. The user tries to make sure it is actually a bug. See [[WordPress:#Before You Report a Bug|Before You Report a Bug (below)]].

1. 用户试着确定那的确是个程序错误。请看看[[WordPress:#Before You Report a Bug|报告程序错误之前 (下面的)]]。

1. If it is determined to be a bug, the user submits the bug report, called a ticket, to Trac, the WordPress bug tracking system. See [[WordPress:#Reporting a Bug|Reporting a Bug (below)]].

1. 如果确定那是个程序错误，用户递交程序错误报告，称之为ticket，递交到Trac，WordPress程序错误追踪系统。请看看[[WordPress:#Reporting a Bug|报告一个程序错误 (下面的)]]。

1. A WordPress developer (who could be a volunteer like you) confirms that the bug does actually exist, and that it should be fixed, and marks it as such in the ticket. See [[WordPress:#Trac Keywords|Trac Keywords list (below)]] and [[WordPress:#Bug Resolutions|Bug Resolutions (below)]].

1. WordPress开发人员（可能像你一样，是个志愿者）证实了的确存在程序错误，而且应该得到解决，并且在ticket对这个错误进行标记。请看看[[WordPress:#Trac Keywords|Trac Keywords 列表(下面的)]] 和 [[WordPress:#Bug Resolutions|程序错误解决方法(下面的)]]。

1. A WordPress developer (which could be you) decides to fix the bug. The developer may choose to take responsibility for the bug by clicking on the Accept ticket option near the bottom of the ticket, though this is not required. Then the developer figures out how to fix the bug, creates one or more patch files, and uploads them to Trac. See [[WordPress:#Patching Bugs|Patching Bugs (below)]]. Also, if you want to help with fixing bugs, but don't know what bugs to fix, see [[WordPress:#Finding Bugs to Fix|Finding Bugs to Fix (below)]].

1. WordPress开发人员（可能是你）决定解决这个程序错误。开发人员可能选择通过点击ticket底部旁边的接受 ticket选项，负责解决程序错误，但是这并不是必须的。然后开发人员思索怎样解决程序错误，创建一个或者更多的补丁文件，并且将这些文件上传到Trac。请看看[[WordPress:#Patching Bugs|Patching Bugs (下面的)]]。同时，如果你想要帮助解决程序错误，但是不知道要解决哪个程序错误问题，请看看[[WordPress:#Finding Bugs to Fix|找到程序错误来解决 (下面的)]]。

1. Members of the WordPress development group (including volunteers) test the patch, to see if it fixes the bug and doesn't break anything else. They add comments and keywords to the ticket to indicate their results. See [[WordPress:#Trac Keywords|Trac Keywords list (below)]].

1. WordPress开发小组的成员（包括志愿者）测试补丁，看看是否能够解决程序错误，同时不会破坏其它的内容。他们给tickets添加评论和keywords，暗示结果。请看看[[WordPress:#Trac Keywords|Trac Keywords list (下面的)]]。

1. One of the WordPress developers with authority to modify the official WordPress source code (Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) commits the patch to the core code in the SVN repository. They are more likely to do this if the bug and patch has been verified by someone they trust.

1. 1. 更改WordPress官方源代码，权威的WordPress开发人员(Matt Mullenweg, Ryan Boren, Mark Jaquith 或者 Peter Westwood) 递交 补丁到SVN资源库的核心代码。如果程序和补丁由某个他们信任的人证实了，开发人员更会这么做。

1. Finally, the person who commits the patch sets the bug ticket status to closed and the resolution to fixed. See [[WordPress:#Bug Resolutions|Bug Resolutions (below)]].

1. 最后，递交补丁的人，将程序错误ticket级别设置为关闭的，将解决办法设置为解决的。请看看[[WordPress:#Bug Resolutions|程序错误解决办法 (下面的)]]。

程序错误报告和解决办法的详细信息

The sections below add details to some of the steps outlined above.

下面的部分，给上面列出的一些步骤，添加了详细信息。

报告程序错误之前

With large projects like WordPress, so many users report bugs that there's a good chance your bug has already been reported. Because of this, it's very important to check to be sure it's not already in the system before you submit it. If you are new to reporting bugs in WordPress, it is also a good idea to discuss the issue with more experienced developers before reporting it. Please follow the steps below.

像WordPress这么大的软件项目，许多用户都会报告程序错误，很有可能你报告的程序错误，其他人已经报告了。因此在递交错误报告之前，看看系统中是否已经存在这样的报告，非常重要。如果对于报告WordPress程序错误，你还是个新手，与有经验的开发人员，讨论这个问题，然后再报告程序错误，这是个好主意。请遵循下面的步骤。

1. Search for your bug or feature request in Trac by using Search or a Query.

1. 通过使用搜索 或者查询搜索你的程序错误或者Trac需求的功能。

1. • If your issue has already been reported, please do not report a duplicate bug. If you have further information to contribute, log in and add a note to the existing bug.

1. 如果你要报告的程序错误，他人已经报告了，请不要重复报告。如果你还需要贡献关于这个错误的更深层次的信息，请登录并且给当前存在的程序错误，添加内容。

1. • If your issue is similar, but not quite the same as another issue, you may decide whether to add a note to the similar issue, or report a new one. It can be difficult to decide whether your issue warrants a new submission, but in general if you just have more information to contribute to a current, open issue, simply add a note to that issue. If you have a different enough issue, or if you are experiencing a recurrence of an issue that was previously resolved, report a new bug.

1. • 如果你报告的程序错误与其他人报告的相似，但是不是完全一样的，你可能决定是否向相似的报告添加一些信息，还是报告一个新的程序错误。决定你的报告是否值得再递交一次，很难。但是遗憾，如果你有更多的信息，可以添加到当前的错误报告了，你可以添加一个便条即可。如果你有足够多的不同的信息，或者你发现了一个先前解决好的程序错误问题有出现了，你可以将其作为一个新的程序错误报告。

1. • If your issue was recently reported and then closed, and you do not agree with the resolution, you can also reopen the ticket and add a comment as to your reasoning.

1. • 如果你发现的程序错误，最近已经有人报告了，但是又关闭了，而且你不同意解决那个错误的方法，你可以再次打开ticket并且根据你的推理 ，再次地添加一个评论。

1. To discuss a bug before reporting it in Trac (e.g. to figure out if it is really a bug in the core of WordPress and not in a plugin or theme), you can post a question on the WordPress Support Forum, discuss your issue on the #wordpress IRC channel, or have an email discussion on the Testers or Hackers mailing list.

1. 讨论程序错误然后再将它报告到Trac（例如，了解程序错误是否真是WordPress核心中的程序错误，而不是插件或者主题中的程序错误），你可以在WordPress 支持论坛上发表一个问题，讨论你在#wordpress IRC channel上遇到的问题，或者在Testers 或者Hackers邮件列表上发邮件讨论这个问题。

报告程序错误

Trac is the name of the official WordPress bug tracker. It uses the open source bug tracking software Trac which is a product from Edgewall Software. Follow these steps to create a good bug report in Trac:

Trac是官方WordPress程序追踪器的名称，使用开放源码程序追踪软件Trac,这个软件是来自Edgewall 软件的一个产品。遵循下面的步骤在Trac中创建一个良好的程序错误报告。

1. Read [[WordPress:#Before You Report a Bug|Before You Report a Bug (above)]], and verify that you have a new bug that is appropriate to report.

1. 阅读[[WordPress:#Before You Report a Bug|报告程序错误之前 的准备(上面的)]]，并且确认你有一个可以报告的程序错误。

1. Read this article on How to Report Bugs Effectively, and the Trac Ticket documentation.

1. 在怎样有效地报告程序错误和Trac Ticket 文档上阅读这篇文章。

1. Log into WordPress Trac using your support forum username and password. If you don't have an account at the support forums, register so that you can login to Trac. This is essential for communication about your bug, since the developers may need more information (and you cannot create a ticket without logging in).

1. 使用支持论坛用户名和密码，登录到WordPress Trac。如果你没有支持论坛的帐户，注册一个帐户，你就可以登录到Trac。这对于探讨程序错误至关重要，因为开发人员可能需要更多的信息（但是你没有登录，就不能创建ticket）。

1. Click New Ticket in Trac to reach the bug reporting page.

1. 点击Trac中的新的Ticket得到报告程序错误的网页。

1. Fill in the following fields on the new ticket page:

1. 在新的ticket网页，填写以下的栏：

1. Short Summary

   Make the summary short but informative and accurate, as this is the ticket title that will be displayed in search results.

1. ；简短的摘录：使得摘录简短，精确，信息明了，因为这是搜索结果中显示的ticket 标题。

1. Full Description

   Fill in a full description of your bug or feature request. Include a description of the problem, steps someone else would have to take to reproduce the problem, maybe an example of the bug in action (i.e. a URL), and a description of why it is a problem worthy of being corrected. Also include information about your platform, such as operating system, web server software, PHP version, MySQL version, and WordPress version. The better your description, the better the chances of having the bug resolved promptly.

1. ；完整的描述：完整地描述程序错误或者需要的功能。包括描述程序错误，其他人复制这个程序错误需要采取的步骤，可能还有一个运转的程序错误的例子（例如URL），以及描述为什么这个程序错误值得修正。同时还包括你的平台的信息，例如操作系统，网络服务器软件，PHP版本，MySQL版本，和WordPress版本。你描述地越好，程序错误得到合理解决的可能性越大。

1. Ticket Properties

1. Ticket属性：

1. Priority

   You will need to decide on a priority for the issue -- this is how urgent the bug is. Unless it is a critical bug, this is best left to the default as developers will usually rank the bug's priority.

1. ：；优先权：你需要决定问题的优先性—意思是程序错误问题有多么严重。除非那是个严重的程序错误问题，最好将这个问题设置为默认的，因为开发人员通常会对程序错误的优先性进行排名。

1. Component

   Select the component of WordPress where the bug was found

1. ：；组成部分：选择发现程序错误的WordPress的那部分。

1. Severity

   The significance of the issue. Select a severity based on how critical you consider the issue to be. If in doubt, leave this option as Normal.

1. ：；重要性：问题的重要性。根据你认为问题有多么重要，给问题选择一个重要性级别。如果有疑问，将这个选项保持为一般的。

1. Assign to

   If you know of the developer who is responsible for the code that the bug is in, place their Trac username here. You can also take responsibility for the bug yourself, by putting your own Trac user name here. This is optional and could speed up developer attention to the bug.

1. ：；递交：如果你知道哪个开发人员负责错误程序的代码，你可以将这个开发人员的Trac用户名放在这儿。你也可以自己对程序错误负责，将你自己的Trac用户名放在这里。这是可选的，也能够加快程序员注意这个程序错误。

1. Milestone

   By what version this issue should be resolved, at the latest. Do not change this. This is an option that WordPress developers will set.

1. ：；最迟在哪个版本，这个程序错误会得到修正。不要更改这个版本数字。这是WordPress开发人员设置的一个选项。

1. Version

   The version of WordPress where the bug was found. You can find the version number of WordPress in the footer of the admin panel.

1. ：；版本：发现程序错误的WordPress版本。你可以在管理面板的页底文字上发现WordPress的版本数字。

1. Keywords

   Keywords that will make it easier for developers to find the bug, and identify the areas it affects. An example might be 'posting' for a bug involving the posting mechanism in WordPress. Also, there are some standard keywords used to flag your bug's status (see [[WordPress:#Trac Keywords|Trac Keywords]] below).

1. ：；关键词：关键词，能够帮助开发人员更轻易地找到程序错误并且识别这个程序错误可能影响的区域。可能会为涉及WordPress posting 机制的程序错误，'posting'一个例子。同时，可以使用一些标准的键，表示程序错误的级别（请看看下面的[[WordPress:#Trac Keywords|Trac Keywords]]）。

1. CC

   Who bug information and updates should be sent to. If you want to be kept informed, enter your own Trac user name here. You will then be notified by email any time a change is made to this report, or a note to the bug is added. Don't ignore these emails; any time a change is made, be sure to check the report for updates. Developers may need further information from you, and this is their only way of getting in contact with you. Note: you need to go to the Trac Settings page to set your email address. Putting it into your Support Forum profile will not get it into Trac for purposes of CC messages.

1. ：；CC：程序错误信息和更新信息，应该发送给谁。如果你希望得到通知，请在这里输入你的Trac 用户名。然后，如果这个程序错误发生了任何更改或者添加了额外信息，你都会得到一封电子邮件的通知。不要忽视这些电子邮件；任何时候这个错误报告更改了，你要确定更新这个报告。开发人员可能需要你提供更深入的信息，这是他们与你联系的唯一方式。注:你可能需要进入Trac 设置网页，设置你的电子邮件地址。将电子邮件地址放到支持论坛你的基本资料中，不能使邮件地址为了CC信息，而进入Trac中。

1. Click Submit Ticket (after previewing it). Then pat yourself on the back.

1. 点击递交Ticket(预览Ticket后)。这样你可以放松了。

查找程序错误并修正

If you want to fix bugs in the core parts of WordPress, but don't know which ones to fix, here are some suggestions on how to find bugs to fix:

如果你想要解决WordPress核心部分的程序错误，但是不知道要解决那个错误，下面有一些提议，关于怎样找到程序错误，对其进行修正：

• Look through the Needs Patch Report on Trac (which lists bugs that have not been marked with the "has_patch" keyword), the Lacks Attachment Report on Trac (which lists bugs that do not have a patch file attached), or other Trac reports for bugs that look interesting.

• 通读Needs Patch Report on Trac(列出了没有标记"has_patch"关键词的程序错误)，Lacks Attachment Report on Trac（列出了没有附加补丁文件的程序错误），或者其它的看起来有趣的程序错误Trac 报告。

• Send an email message to the wp-hackers mailing list and ask how you can help.

• 向wp-hackers 邮件列表发送一封电子邮件，并且询问你可以怎么帮忙。

• There is also sometimes bug triage on the #wordpress-dev WordPress:IRC channel

• 还有一些程序错误在#wordpress-dev WordPress:IRC channel上优先得到修正

• Occasionally there are bug days on #wordpress-bugs. You can read about what happens in a bug day in WordPress:WordPress Bug Hunts, and subscribe to either the wp-hackers or wp-testers mailing list to find out when they happen.

• 有时候#wordpress-bugs上会有程序错误日。你可以在WordPress程序错误搜索上阅读，程序错误日那天发生了什么事，并且订阅wp-hackers 或者wp-testers列表，看看程序错误日是哪一天。

• Consider joining the wp-trac email list to follow the discussions about each Trac Ticket.

• 考虑加入wp-trac 电子邮件列表看看关于每个Trac Ticket的讨论。

修补程序错误

If you and are familiar with PHP and MySQL, and would like to help in the development of WordPress, then you are encouraged to patch WordPress bugs. Here are the steps to follow:

如果你熟悉PHP 和MySQL，并且希望在WordPress发展过程中，尽自己的一臂之力，你可以解决程序错误问题。下面是一些你可以遵循的步骤：

1. Read [[WordPress:#Finding Bugs to Fix|Finding Bugs to Fix (above)]], and find a bug to fix in Trac.

1. 请阅读[[WordPress:#Finding Bugs to Fix|查找修正程序错误 (上面的)]]，查找程序错误，在Trac中修正。

1. Connect to the WordPress Subversion (SVN) Repository using the username and password you acquired when registering. Read WordPress:Using Subversion if you are unfamiliar with SVN. All patches should be submitted against the latest code in the SVN repository.

1. 连接到WordPress 子版本(SVN) 资源库，注册时，使用你得到的用户名和密码。如果你不熟悉子版本，请阅读使用子版本。所有的补丁都必须根据子版本资源库中最新的代码，递交。

1. Figure out how to fix the bug, by modifying WordPress core files. You may want to discuss your proposed solution on the wp-hackers mailing list before finalizing it.

1. 了解怎样通过更改WordPress核心文件，解决程序错误问题。你可能希望在wp-hackers 邮件列表上讨论你建议的解决办法，再最后决定使用这个方法。

1. Test your fix, verifying that the bug has been fixed, and that nothing else in WordPress is broken in the process.

1. 测试你的方法，确认程序错误已经得到了解决，而且在解决过程中，WordPress中的其它内容都没有受损。

1. Create a patch file (or files) containing your fix. This is basically a diff of the fixed file(s) and the originals from SVN. See How to Patch WordPress by Owen Winkler for detailed instructions. There are also instructions for Linux/Mac command-line users in Mark Jaquith's Toolbox and Windows Tortoise SVN users in Westi's Blog.

1. 创建一个(或者多个)包含解决方法的补丁文件。这基本上是固定文件的diff，而且是SVN的原始资料。请看看Owen Winkler的怎样修补WordPress上面的详细指示。在Mark Jaquith's Toolbox上也有对于Linux/Mac 命令行用户的指导和Westi的博客上的Windows Tortoise SVN用户的指导。

1. Upload it to the ticket using the Trac Attach file button, and add has-patch to the keywords. If the patch needs testing, you might also put needs-testing, or one of the other Trac keywords; see [[WordPress:#Trac Keywords|Trac Keywords (below)]] for more information.

1. 使用Trac 附加文件按钮，将其上传到ticket上，并且将has-patch添加到关键词上。如果补丁需要测试，你可能需要加入需要测试，或者其它的某个Trac关键词；更多的信息，请看看[[WordPress:#Trac Keywords|Trac 关键词 (下面的)]]

Trac 关键词

There are a number of keywords with defined meaning used in Trac that are commonly used; some are also searched for by Trac Reports.

有许多关键词，拥有规定的意思，用在经常使用的Trac中；有的关键词也可以通过Trac报告搜索。

reporter-feedback

A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.

报告人员反馈

需要来自报告人员的反馈信息。如果没有来自遇到这个程序错误的人员的响应信息，就很难进行深入的调查。

has-patch

A solution to the ticket has been attached, and it is ready for review and/or committing.

has-patch

附加ticket的一个解决方法，而且可以阅读和/或者递交这个方法。

needs-testing

Someone needs to test the solution.

需要测试

有的人需要测试这个解决方法。

2nd-opinion

Another person is needed to express an opinion about the problem or the solution.

第二种观点

另一个人需要对问题或者解决方法提出自己的观点。

dev-feedback

A response is wanted from a developer (not commonly used)

dev-feedback

需要来自开发人员的回应(不经常使用)

tested

The patch has been tested. When adding this tag please comment with the patch filename that was tested, how the patch was tested, and which version of WordPress was used (including the SVN revision number, if it is not an officially released version).

tested

补丁需要经过测试。添加这个标签的时候，请用经过测试后的文件名评论，补丁是怎样测试的，使用的是WordPress的哪个版本（如果不是官方发行的版本，包括SVN修订数字）。

commit

The patch has been reviewed and tested by a trusted member of the development community; therefore the patch is ready to be added to the WordPress core files.

commit

补丁有发展团队中一名可以信任的队员阅读并测试了；那么补丁就要添加到WordPress核心文件了。

needs-patch

The ticket has been reviewed, found to be desirable to solve, and marked as especially needing a patch, or the submitted patch doesn't work and needs to be redone.

needs-patch

ticket已经得到了浏览，而且发现需要解决程序错误问题，同时标记为特别需要修补，或者如果不能够递交补丁，就需要重新递交。

needs-unit-tests

The ticket has been reviewed, found to be desirable to solve and we would like some unit tests written to test the functionality and any patch that may exist before committing a change as the risk of causing other issues is high.

needs-unit-tests

:ticket已经得到了浏览，而且发现需要解决程序错误问题，我们希望编写一些unit测试，测试泛函性以及任何可能存在的补丁，再做出更改，以防止导致其它更严重的问题。

needs-doc

Inline documentation for the code is needed. These are either place holder tickets for individual files or tickets with patches for new functions which need documenting before they are committed.

needs-doc

需要代码的inline文档。这些是单个文件的place holder或者是拥有补丁的需要证明才能递交的新函数的ticket的place holder。

解决程序错误的方法

A ticket in Trac starts its life in the open status, and (hopefully) is eventually closed. When a ticket is closed, it is marked with one of the following status designations:

Trac中的ticket从打开的status开始运行，而且（希望）是最终关闭的。当一个ticket关闭的时候，ticket标记有下面的其中一个级别：

• If your bug has been reported elsewhere, it will likely be closed with duplicate.

• 如果你的程序错误是在其它位置报告的，ticket关闭时，带有复制级别。

• If the bug has already been fixed in the latest subversion code (which is probably not what you're running unless you have a local test blog), then it will be closed with fixed.

如果程序错误在最新的子版本代码中已经修正了（除非你有一个本地测试博客，否则子版本代码并不是你运行的内容），ticket关闭时，拥有已解决级别。

• If it is decided that your bug isn't in fact a bug, but is the intended behaviour, it will be closed with invalid.

• 如果确定你报告的程序错误事实上并不是一个错误，而是一个正常的代码，那么ticket关闭时，会标有无效的。

• If no-one else can replicate the symptoms you describe, it will be closed with worksforme.

• 如果你没有人能够复制你描述的符号，那么ticket关闭时候，会标有worksforme。

• If your bug is a feature request that the developers don't want in the core, it will be marked as wontfix.

• 如果你报告的程序错误是个功能请求，但是开发人员并不想在WordPress核心中添加这个功能，那么ticket关闭时，会标有wontfix。

Please verify that your bug doesn't fall into one of these categories before submission.

在递交程序错误之前，请确认你发现的程序错误不属于以上的任何一类。

注意

• The processing of your bug may require your participation. Please be willing and prepared to aid the developers in resolving the issue.

• 处理程序错误，可能需要你的参与。请乐意准备帮助程序员解决程序错误问题。

• Don't be upset if your bug gets resolved as "Not a bug" or "Won't fix". What seems like a bug to you may very well be a "feature". These resolutions just mean "not going to fix now", maybe in the future it will be a priority to solve.

• 如果你报告的程序错误"不是程序错误" 或者 "不能够解决"，请不要焦虑不安。你认为是程序错误的内容，可能是个"feature"。这里只是指"现在不解决"，但是将来某天可能会首先解决这个程序问题。

• Thank you for contributing to the development of WordPress!
• 非常感谢你对WordPress的发展做贡献！