编辑“WordPress:Submitting Bugs”

每种软件都有[[WordPress:Wikipedia:Computer bug|错误]] – 只要是人写代码，软件中就会有错误，有些错误是微不足道的，但是有些是非常严重的。开源项目如 [[WordPress:WordPress| WordPress]] 需要使用者的参与来找出软件中的错误，同样也包括新功能的开发。
所有类型的反馈&mdash; 不管是真正的错误还是有用的请求&mdash; 都在WordPress 中用同样的方法提交。阅读WordPress关于如何提交错误和问题的信息... 你可能会想要阅读[[WordPress:Contributing to WordPress|为WordPress做贡献]]来找出如何为文档资料和WordPress其他方面做贡献。

== 提交安全问题 ==

当我们试着防止出现安全问题时，我们不能认为它们不会出现。如果你相信你在WordPress某个版本中找到了安全问题，发邮件到<tt>WordPress.org</tt>上的<tt>security</tt> 区域，我们将尽力尽快解决。

通知卖主(这里是指WordPress开发人员)是在发布之前的安全问题的标准练习，这样可以准备好修正版本，这造成的损失可以降低到最小。

== 提交插件和主题中的错误 ==

如果你在使用时插件或者主题中发现了错误，'''不要''' 使用本文中的方法进行提交! 本文提供的方法只适用于WordPress核心文件的错误，不适合于插件和主题中的错误。

[http://dev.wp-plugins.org/ WordPress插件库]中的插件有一个来自 WordPress 核心的[http://dev.wp-plugins.org/report 单独的错误跟踪系统]。有一个如何使用这个系统的 [http://dev.wp-plugins.org/wiki/TracTickets 单独的说明]。

对于不在官方库中的插件和主题，查看其附带的文档资料作为关于如何提交错误的说明。如果没有错误提交信息，你需要直接联系作者。


==错误提交和解决总览==

提交和解决WordPress错误的过程有几步，这里是一个总的概括，下面可以找到更多细节。 
# 用户发现了错误，出现在WordPress核心文件中 (不在主题或者插件中).
# 用户尝试着确认这确实是一个错误。参见 [[#WordPress:Before You Report a Bug|提交错误之前(下面)]].
# 如果确定它是一个错误，用户提交错误报告到[http://trac.wordpress.org/ Trac]，叫做''ticket''，WordPress错误跟踪系统。参见[[#WordPress:Reporting a Bug|提交错误 (下面)]]. 
# WordPress 开发人员 (可能也是象你一样的志愿者) 确认错误的确存在，然后它应该被修正。然后象在票上做记号那样标记出来。参见[[#WordPress:Trac Keywords|Trac 关键词列表(下面)]] 和 [[#WordPress:Bug Resolutions|错误解决方案(下面)]].
# WordPress 开发人员 (可能是你)决定修复这个错误。开发者可能选择通过点击ticket底部附近的 ''Accept ticket''操作来负责这个错误，尽管这不是必须的。然后开发人员指出如何修复这个错误，创建一个或者多个补丁，上传到Trac. 参见 [[#WordPress:Patching Bugs|错误补丁(下面)]]。同样的，如果你想要帮助修复错误，但是不知道需要修复哪个错误，参见[[#WordPress:Finding Bugs to Fix|找到错误并修复 (下面)]].
# WordPress开发小组成员(包括志愿者)测试补丁，查看是否错误被修复了而没有影响到其他东西。它们添加评论和关键词到ticket，显示出它们的结果。参见 [[#WordPress:Trac Keywords|Trac 关键词列表(下面)]].
# WordPress 开发员中的一个拥有修改官方WordPress源代码权限的人(Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) ''提交'' 补丁给SVN库中的核心代码。如果错误和补丁被他们所信任的某人验证过后，他们会这样做的。
# 最后，提交补丁的这个人设定ticket状态为''closed''，结论是''fixed''。参见 [[#WordPress:Bug Resolutions|错误结论(下面)]].

==Details of Bug Reporting and Resolution==

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

==错误报告和解决方案的详细内容==

下面的部分给上述的提纲添加了详细内容。

=== Before You Report a Bug ===

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中使用提交错误，在提交之前和有经验的开发人员讨论这个问题是个好办法。请按照下面的步骤。

# Search for your bug or feature request in Trac by using [http://trac.wordpress.org/search Search] or a [http://trac.wordpress.org/query Query].
#* 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.
#* 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.
#* 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.
# 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 [http://wordpress.org/support/ WordPress Support Forum], discuss your issue on the [[WordPress:WordPress IRC Live Help|#wordpress IRC channel]], or have an email discussion on the [[WordPress:Mailing Lists#Testers|Testers]] or [[WordPress:Mailing Lists#hackers|Hackers]] mailing list. 

# 在Trac中通过使用[http://trac.wordpress.org/search 搜索]或者是[http://trac.wordpress.org/query 查询]来查找你的错误或者是功能请求。
#* 如果你的问题已经被提交过了，请不要重复提交。如果你有更深入的信息，登陆并添加信息记录到已存在的错误中。
#* 如果你的问题相似，但是不完全和另一个问题相同，你可以决定是否添加一个记录到相似问题中，或者是重新提交。很难决定是否你的问题可以作为一个新的问题提交，但是通常情况下，如果你只是有更多信息来提交的话，打开问题，简单的添加一个记录就可以了。 如果你有个完全不同的问题，或者如果你正经历了一个重复的以前解决过的问题，可以提交一个新错误。
#* 如果你的问题最近提交了也关闭了，但是你不同意这样的解决方法，你可以重新打开ticket添加注释，写明你的理由。
# 想在Trac上在提交之前讨论一个错误， (如判断它是否是一个WordPress核心的而不是插件或者主题的错误)，你可以在[http://wordpress.org/support/ WordPress 支持论坛]上发个帖子，在[[WordPress:WordPress IRC Live Help|#wordpress IRC 频道]] 讨论你的问题，或者在[[WordPress:Mailing Lists#Testers|检测器]] 或[[WordPress:Mailing Lists#hackers|Hackers]]邮件列表上参与邮件讨论。

=== Reporting a Bug ===

[http://trac.wordpress.org/ Trac] is the name of the official WordPress bug tracker. It uses the open source bug tracking software [http://projects.edgewall.com/trac/ Trac] which is a product from [http://www.edgewall.com/ Edgewall Software]. Follow these steps to create a good bug report in Trac:

=== 提交错误 ===

[http://trac.wordpress.org/ Trac]是官方WordPress错误跟踪器的名字。它使用开发源码跟踪软件[http://projects.edgewall.com/trac/ Trac]，它是 [http://www.edgewall.com/ Edgewall Software]的产品。安装下面的步骤在Trac建立一个好的错误报告:

# 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.
# Read this article on [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively], and the [http://trac.wordpress.org/wiki/TracTickets Trac Ticket documentation].
# Log into [http://trac.wordpress.org/ WordPress Trac] using your [http://wordpress.org/support/ support forum] username and password. If you don't have an account at the support forums, [http://wordpress.org/support/register.php 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).
# Click '''[http://trac.wordpress.org/newticket New Ticket]''' in Trac to reach the bug reporting page.

# 阅读 [[WordPress:#Before You Report a Bug|提交错误之前(上面)]], 然后验证你有一个新的可以提交的错误。
# 阅读[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html 如何有效的提交错误]这个文章，和[http://trac.wordpress.org/wiki/TracTickets Trac Ticket 文档].
#使用你的 using your [http://wordpress.org/support/ 支持论坛]的用户名和密码登陆[http://trac.wordpress.org/ WordPress Trac]。如果你没有帐户， [http://wordpress.org/support/register.php 注册] 一个这样才可以登陆Trac。这队伍你错误的交流是必需的。因为开发人员可能需要更多的信息(而你不能创建ticket 如果不登陆的话).
# 点击Trac中 '''[http://trac.wordpress.org/newticket New Ticket]''' 打开错误提交页面。
# Fill in the following fields on the new ticket page:
#; Short Summary: Make the summary short but informative and accurate, as this is the ticket title that will be displayed in search results.
#; 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.
#; Ticket Properties:
#:; 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.
#:; Component: Select the component of WordPress where the bug was found
#:; 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''.
#:; 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.
#:; 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.
#:; 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.
#:; 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).
#:; 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.
# Click '''Submit Ticket''' (after previewing it). Then pat yourself on the back.

# 在新的ticket页面上填写如下信息:
#; 简单摘要: 让摘要简短但是要包含信息并且准确，因为这是ticket的标题，将会显示在搜索结果中。
#; 完整的描述: 填写你的错误或者是功能要求的完整的描述。包括一个问题的描述，别人可以重复这个问题的步骤，也可以是一个错误的运转的例子 (如 URL), 或者是一个为什么问题值得更正的描述。同样包括关于你的平台的信息，如操作系统，网络服务器软件，PHP 版本, MySQL 版本, WordPress 版本。你描述的越好，解决错误的可能性就越大。
#; Ticket 属性:
#:; 优先级: 你需要确定这个问题的优先权 – 这个错误有多紧急。除非它是一个致命的错误，最好是让它保持默认状态，因为开发人员通常都是按照错误优先级的排序来的。
#:; 组件: 选择发现问题所在的WordPress组件
#:; 严重 : 这个问题的''重要性''。选择一个severity基于你认为这个问题有多严重，如果有疑问，就保持默认的''Normal''.
#:; 分配: 如果你知道有负责存在错误的代码的开发人员，把他们的Trac用户名放在这里。你也可以自己为这个错误负责，把你自己的Trac用户名放在这里就可以了。这是可以选择的，这可以让开发人员更快的注意到这个错误。
#:; 里程表: 最迟在哪个版本这个问题会被解决。不要更改它。这是WordPress 开发人员设置的。
#:; 版本: 错误发现的WordPress 版本。你可以在管理面板的页脚找到WordPress版本号。
#:; 关键词: 关键词让开发人员更容易的找到错误所在，确定它的影响范围。例如'posting'， 一个涉及到WordPress发表文章机制的错误的关键词。同样，有标准关键词用来标记你的错误的状态(参见 [[WordPress:#Trac Keywords|Trac 关键词]] 下面).
#:; CC: 错误信息和更新信息发送的对象。如果你想保持可以被通知到，把你自己的Trac名字写上。 当这个报告有任何更改的时候，你将会被邮件通知。不要忽视这些邮件; 做出任何改动后，确定查看一下报告更新。开发人员可能需要从你这里获得更多的信息，这是他们与你联系的唯一的方法。 '''注意''': 你需要进入Trac ''设置''页面来设置你的email地址。把他放到你的支持论坛个人资料里并不能让你的资料进入Trac以达到接收CC信息的目的。
# 点击 '''提交Ticket''' (预览之后). 然后返回。

=== Finding Bugs to Fix ===

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:
* Look through the [http://trac.wordpress.org/report/13 Needs Patch Report on Trac] (which lists bugs that have not been marked with the "has_patch" keyword), the [http://trac.wordpress.org/report/18 Lacks Attachment Report on Trac] (which lists bugs that do not have a patch file attached), or other [http://trac.wordpress.org/report Trac reports] for bugs that look interesting.
* Send an email message to the [[WordPress:Mailing_Lists#Hackers|wp-hackers mailing list]] and ask how you can help. 
* There is also sometimes bug triage on the <tt>#wordpress-dev</tt> [[WordPress:IRC]] channel
* Occasionally there are bug days on <tt>#wordpress-bugs</tt>. You can read about what happens in a bug day in [[WordPress:WordPress Bug Hunts]], and subscribe to either the [[WordPress:Mailing_Lists#Hackers|wp-hackers]] or [[WordPress:Mailing_Lists#Testers|wp-testers]] mailing list to find out when they happen.
* Consider joining the [http://lists.automattic.com/mailman/listinfo/wp-trac wp-trac email list] to follow the discussions about each [http://trac.wordpress.org/report Trac Ticket]. 

=== 找到错误修正 ===

如果你想修正WordPress核心部分的错误，但是不知道修正哪个，这里是一些关于如何找到修正的错误的建议:
* 仔细阅读 [http://trac.wordpress.org/report/13 需要关于Trac的补丁报告] (列出了没有标出"has_patch"关键词的错误)， [http://trac.wordpress.org/report/18 缺乏关于Trac的附件报告] (列出了没有补丁文件的错误)，或者是其他对于看起来比较有趣的错误的 [http://trac.wordpress.org/report Trac 报告].
* 发送邮件信息到[[WordPress:Mailing_Lists#Hackers|wp-hackers 邮件列表]] 询问你能帮什么忙. 
* 有时也有一些错误帮助在 <tt>#wordpress-dev</tt> [[WordPress:IRC|IRC]] 频道。
* 偶然在<tt>#wordpress-bugs</tt>上有错误日。你可以在[[WordPress:WordPress Bug Hunts|错误搜寻]]上阅读关于什么错误日发生了什么，并且预定[[WordPress:Mailing_Lists#Hackers|wp-hackers]]或者是 [[WordPress:Mailing_Lists#Testers|wp-testers]] 邮件列表来找出它们是什么时候出现的。
* 考虑加入[http://lists.automattic.com/mailman/listinfo/wp-trac wp-trac 邮件列表] 来参与关于每个[http://trac.wordpress.org/report Trac Ticket]的讨论。

=== Patching Bugs ===

If you and are familiar with [[WordPress:Glossary#PHP|PHP]] and [[WordPress:Glossary#MySQL|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:

#Read [[WordPress:#Finding Bugs to Fix|Finding Bugs to Fix (above)]], and find a bug to fix in [http://trac.wordpress.org Trac].
#Connect to the [http://wordpress.org/download/svn/ WordPress Subversion (SVN) Repository] using the username and password you acquired when [http://wordpress.org/support/register.php registering]. Read [[WordPress:Using Subversion]] if you are unfamiliar with SVN.  All patches should be submitted against the latest code in the SVN repository.
# Figure out how to fix the bug, by modifying WordPress core files. You may want to discuss your proposed solution on the [[WordPress:Mailing_Lists#Hackers|wp-hackers mailing list]] before finalizing it.
# Test your fix, verifying that the bug has been fixed, and that nothing else in WordPress is broken in the process.
# 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 [http://asymptomatic.net/2005/12/03/586/how-to-patch-wordpress How to Patch WordPress by Owen Winkler] for detailed instructions. There are also instructions for Linux/Mac command-line users in [http://markjaquith.wordpress.com/2005/11/02/my-wordpress-toolbox/ Mark Jaquith's Toolbox] and Windows Tortoise SVN users in [http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/ Westi's Blog].
# Upload it to the ticket using the [http://trac.wordpress.org/ 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.

=== 打补丁 ===

如果你熟悉[[WordPress:Glossary#PHP|PHP]]和 [[WordPress:Glossary#MySQL|MySQL]]，并且想帮助WordPress发展，那么我们鼓励你为WordPress 的错误打上补丁。如下是打补丁的步骤:

#阅读 [[WordPress:#Finding Bugs to Fix|找到错误修正(上面)]], 然后在[http://trac.wordpress.org Trac]中找到错误并修正
#使用你[http://wordpress.org/support/register.php 注册]的用户名和密码连接到[http://wordpress.org/download/svn/ WordPress Subversion (SVN) Repository]，阅读 [[WordPress:Using Subversion|使用子版本]]，如果你对SVN不熟悉的话。所有的补丁都会被提交的SVN，而不考虑最新的代码。
# 找出如何通过修改WordPress核心文件修正错误。你可能想在结束之前在[[WordPress:Mailing_Lists#Hackers|wp-hackers 邮件列表]]上讨论你的解决方案。
# 测试你的修改，验证错误已经被修正，而且在此过程中没有其他的WordPress内的东西被破坏。
# 创建一个包含你的修改的''补丁文件''。这完全与修正文件和SVN中的源文件''不同''。参见[http://asymptomatic.net/2005/12/03/586/how-to-patch-wordpress 如何为WordPress打补丁 by Owen Winkler]获得详细说明。有Linux/Mac 的说明，[http://markjaquith.wordpress.com/2005/11/02/my-wordpress-toolbox/ Mark Jaquith 的工具书]中的命令行使用者，和[http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/ Westi的Blog]中Windows Tortoise SVN 的使用者.
# 使用[http://trac.wordpress.org/ Trac]的 ''Attach file'' 按钮上传到ticket，添加 ''has-patch''到关键词中。如果补丁需要测试，你可以把''needs-testing''也添加上，或者其他的Trac 关键词; 参见 [[WordPress:#Trac Keywords|Trac 关键词 (下面)]] 获得更多信息。

=== Trac Keywords ===

There are a number of keywords with defined meaning used in [http://trac.wordpress.org Trac] that are commonly used; some are also searched for by [http://trac.wordpress.org/report Trac Reports].

;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.

;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)

;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).

;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.

;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-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-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.


=== Trac 关键词 ===

有很多有固定意思的关键词经常在[http://trac.wordpress.org Trac]中使用; 一些可以通过[http://trac.wordpress.org/report Trac Reports]搜索。

;reporter-feedback : 提交人的回复是必需的。深入的调查如果没有经历过问题本身的人的回复的话是靠不住的。

;has-patch : 已经附上ticket的解决方法，准备好再次检查或者是提交。

;needs-testing : 某人需要测试这个解决方案

;2nd-opinion : 需要另外一个人来传递一个关于问题或者解决方案的观点

;dev-feedback : 需要开发人员的回复 (不常用)

;tested : 补丁测试过了. 当添加这个标签时请加入测试的文件名字，补丁如何测试的，和使用了哪个WordPress版本(包括SVN版本号，如果不是官方发布的版本的话).

;commit : 补丁已经被某个开发团体中可以信任的人检查过，测试过; 这样这个补丁就已经准备添加到WordPress核心文件中了.

;needs-patch : ticket已经被检查过，发现描述为解决，但是标记为特别需要一个补丁，或者提交的补丁不能使用需要重新做

;needs-unit-tests : ticket已经通过检查，发现描述为解决，我们希望一个联合测试，来测试功能性，因为提交前各种补丁的存在造成导致其他问题的风险很高。

;needs-doc : 需要代码的内嵌文档。这可以是在它们被提交之前保存ticket单独文件或者是带有新函数补丁需要的文档资料。 

=== Bug Resolutions ===

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:

* If your bug has been reported elsewhere, it will likely be closed with ''duplicate''. 
* 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''.
* If it is decided that your bug isn't in fact a bug, but is the intended behaviour, it will be closed with ''invalid''.
* If no-one else can replicate the symptoms you describe, it will be closed with ''worksforme''.
* If your bug is a feature request that the developers don't want in the core, it will be marked as ''wontfix''.

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

=== 错误解决方案===

Trac 中的ticket 在''open''状态下开始，最终到''closed''。当一个ticket关闭后，它会被以下某个状态之一标记:

* 如果你的错误已经提交到别的地方，它将以''duplicate''结束. 
* 如果错误在最新的版本代码中已经修正(可能不是你在运行的版本除非你有一个本地测试的blog)，标记为''fixed''.
* 如果确定你的错误事实上不是错误，而是你故意的行为，会标记为''invalid''.
* 如果没有其他人可以重现你所描述的现象，会以''worksforme''结束。
* 如果你的错误是一个功能请求，而开发人员不想让它出现在核心代码中，标记为 ''wontfix''.

请验证你的错误在提交时不属于其中任何一种。

== Notes ==

* 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.
* Thank you for contributing to the development of WordPress!

== 注 ==

* 你的错误的处理过程可能需要你的参与，希望你自愿并准备好帮助开发人员解决问题。
* 如果你的问题被解决为"Not a bug" 或者 "Won't fix"时不要生气，看起来对你是错误的东西很可能是一种"功能". 这些解决方法只是意味这"现在不能解决", 可能将来会被解决的.
* 感谢为WordPress做出的贡献!