From 10bb07def547c7cb825fcdc128176f34ee6f075d Mon Sep 17 00:00:00 2001
From: WuzgXY <62000315+WuzgXY-GitHub@users.noreply.github.com>
Date: Mon, 25 Jan 2021 09:21:44 +0800
Subject: [PATCH] =?UTF-8?q?=E6=96=87=E6=B3=95=E4=B8=A8=E5=85=B6=E5=AE=83->?=
=?UTF-8?q?=E5=85=B6=E4=BB=96=E4=B8=A8=E4=B8=BA=E5=8C=85=E5=90=AB=E9=A1=BF?=
=?UTF-8?q?=E5=8F=B7=EF=BC=88=E3=80=81=EF=BC=89=E7=9A=84=E6=A0=87=E9=A2=98?=
=?UTF-8?q?=E6=8F=90=E4=BE=9B=E8=B7=B3=E8=BD=AC=E6=94=AF=E6=8C=81?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
事实上按照权威词典的解释「其它」不如「其他」规范，但考虑到「其它」有助于区分讨论对象的类别并且它符合较多人的阅读/书写习惯，因此仅对错误之处作修改
---
README-zh_CN.md | 60 +++++++++++++++++++++++++------------------------
1 file changed, 31 insertions(+), 29 deletions(-)
diff --git a/README-zh_CN.md b/README-zh_CN.md
index 975ff08..5033093 100644
--- a/README-zh_CN.md
+++ b/README-zh_CN.md
@@ -13,7 +13,7 @@ Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
本中文指南是基于原文 3.10 版以及 2010 年由 [Gasolin](https://github.com/gasolin) 所翻译版本的最新翻译；
-协助指出翻译问题，**请[发 Issue](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/issues/new)，或直接[发 Pull Request](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/compare) 给我。**
+协助指出翻译问题，**请[发 issue](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/issues/new)，或直接[发 pull request](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/compare) 给我。**
本文另有[繁體中文版](README.md)。
@@ -30,7 +30,7 @@ Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
* [第二步，使用项目邮件列表](#第二步使用项目邮件列表)
* [使用有意义且描述明确的标题](#使用有意义且描述明确的标题)
* [使问题容易回复](#使问题容易回复)
- * [用清晰、正确、精准且语法正确的语句](#用清晰、正确、精准且语法正确的语句)
+ * [使用清晰、正确、精准且合乎语法的语句](#使用清晰、正确、精准且合乎语法的语句)
* [使用易于读取且标准的文件格式发送问题](#使用易于读取且标准的文件格式发送问题)
* [精确地描述问题并言之有物](#精确地描述问题并言之有物)
* [话不在多而在精](#话不在多而在精)
@@ -67,7 +67,7 @@ Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
我们已经深刻领教到少了上述声明所带来的痛苦。因为少了这点声明，我们不停地被一些白痴纠缠。这些白痴认为既然我们发布了这本指南，那么我们就有责任解决世上所有的技术问题。
-如果你因寻求某些帮助而阅读本指南，并在离开时还觉得可以从本文作者这里得到直接帮助，那你就是我们之前说的那些白痴之一。别问我们问题，我们只会忽略你。我们在这本指南中是教你如何从那些真正懂得你所遇到软件或硬件问题的人取得协助，而 99% 的情况下那不会是我们。除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家，否则请不要打扰我们，这样大家都会开心一点。
+如果你因寻求某些帮助而阅读本指南，并在离开时还觉得可以从本文作者这里得到直接帮助，那你就是我们之前说的那些白痴之一。别问我们问题，我们只会忽略你。我们在这本指南中想教你如何从那些真正懂得你所遇到的软件或硬件问题的人处取得协助，而 99% 的情况下那不会是我们。除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家，否则请不要打扰我们，这样大家都会开心一点。
## 简介
@@ -144,15 +144,15 @@ Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
一般来说，在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点，一是看潜在的回复者有多少，二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。
-可以理解的是，老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 —— 已经好几次了，一些热门软件的作者从自己软件的支持中抽身出来，因为伴随而来涌入其私人邮箱的无用邮件变得无法忍受。
+可以理解的是，老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 —— 已经好几次了，一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。
### Stack Overflow
-搜索，**然后** 在 Stack Exchange 问。
+搜索，**然后**在 Stack Exchange 问。
近年来，Stack Exchange 社区已经成为回答技术及其他问题的主要渠道，尤其是那些开放源码的项目。
-因为 Google 索引是即时的，在看 Stack Exchange 之前先在 Google 搜索。有很高的机率某人已经问了一个类似的问题，而且 Stack Exchange 网站们往往会是搜索结果中最前面几个。如果你在 Google 上没有找到任何答案，你再到特定相关主题的网站去找。用标签（Tag）搜索能让你更缩小你的搜索结果。
+因为 Google 索引是即时的，在看 Stack Exchange 之前先在 Google 搜索。有很高的几率某人已经问了一个类似的问题，而且 Stack Exchange 网站们往往会是搜索结果中最前面几个。如果你在 Google 上没有找到任何答案，你再到特定相关主题的网站去找。用标签（Tag）搜索能让你更缩小你的搜索结果。
Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/sites)，以下是最常用的几个站：
@@ -178,7 +178,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
* 任何好到需要向个别开发者提出的问题，也将对整个项目群组有益。反之，如果你认为自己的问题对整个项目群组来说太愚蠢，也不能成为骚扰个别开发者的理由。
* 向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导人）也许太忙以至于没法回答你的问题。
- * 大多数邮件列表都会被存档，那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答，将来其它人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。
+ * 大多数邮件列表都会被存档，那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答，将来其他人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。
* 如果某些问题经常被问到，开发者可以利用此信息来改进说明文件或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。
如果一个项目既有"使用者" 也有"开发者"（或"黑客"）邮件列表或论坛，而你又不会动到那些源代码，那么就向"使用者"列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音。
@@ -218,7 +218,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
在论坛，要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感（有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。如果你只是想在有人回复讨论串时得到电子邮件提醒，可以要求网页论坛发送给你。几乎所有论坛都支持诸如`追踪此讨论串`、`有回复时发送邮件提醒`等功能。
-### 用清晰、正确、精准且语法正确的语句
+### 使用清晰、正确、精准且合乎语法的语句
我们从经验中发现，粗心的提问者通常也会粗心的写程序与思考（我敢打包票）。回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。
@@ -241,19 +241,21 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
> If you speak $LANGUAGE, please email/PM me;
> I may need assistance translating my question.
-* 如果你说**某语言**，请寄信/私讯给我；我需要有人协助我翻译我的问题。
+* 如果你说**某语言**，请向我发电邮/私信；
+* 我需要有人协助我翻译我的问题。
> I am familiar with the technical terms,
> but some slang expressions and idioms are difficult for me.
-* 我对技术名词很熟悉，但对于俗语或是特别用法比较不甚了解。
+* 我对技术名词很熟悉，但对于俗语或是特别用法不甚了解。
> I've posted my question in $LANGUAGE and English.
> I'll be glad to translate responses, if you only use one or the other.
-* 我把我的问题用**某语言**和英文写出来，如果你只用一种语言回答，我会乐意将其翻译成另一种。
+* 我把我的问题用**某语言**和英文写出来。
+* 如果你只用其中的一种语言回答，我会乐意将回复翻译成为你使用的语言。
### 使用易于读取且标准的文件格式发送问题
@@ -298,7 +300,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
当你在使用软件中遇到问题，除非你非常、**非常**的有根据，不要动辄声称找到了 Bug。提示：除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你都多半不够完全确信。这同样适用在网页和文件，如果你（声称）发现了文件的`Bug`，你应该能提供相应位置的修正或替代文件。
-请记得，还有许多其它使用者没遇到你发现的问题，否则你在阅读文件或搜索网页时就应该发现了（你在抱怨前[已经做了这些，是吧](#在提问之前)？）。这也意味着很有可能是你弄错了而不是软件本身有问题。
+请记得，还有其他许多使用者没遇到你发现的问题，否则你在阅读文件或搜索网页时就应该发现了（你在抱怨前[已经做了这些，是吧](#在提问之前)？）。这也意味着很有可能是你弄错了而不是软件本身有问题。
编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有`Bug`时，这尤其严重。
@@ -356,7 +358,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
黑客们认为问题的解决过程应该公开、透明，此过程中如果更有经验的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为提供帮助者可以得到一些奖励，奖励就是他的能力和学识被其他同行看到。
-当你要求私下回复时，这个过程和奖励都被中止。别这样做，让**回复者**来决定是否私下回答 —— 如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅，以至于对其它人没有兴趣。
+当你要求私下回复时，这个过程和奖励都被中止。别这样做，让**回复者**来决定是否私下回答 —— 如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅，以至于不可能使其他人产生兴趣。
这条规则存在一条有限的例外，如果你确信提问可能会引来大量雷同的回复时，那么这个神奇的提问句会是`向我发电邮，我将为论坛归纳这些回复`。试着将邮件列表或新闻群组从洪水般的雷同回复中解救出来是非常有礼貌的 —— 但你必须信守诺言。
@@ -368,7 +370,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
要理解专家们所处的世界，请把专业技能想像为充裕的资源，而回复的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。
-所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此，问`我想更好的理解 X，可否指点一下哪有好一点说明？`通常比问`你能解释一下 X 吗？`更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
+所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此，问`我想更好地理解 X，可否指点一下哪有好一点说明？`通常比问`你能解释一下 X 吗？`更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
### 询问有关代码的问题时
@@ -410,7 +412,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
彬彬有礼，多用`请`和`谢谢您的关注`，或`谢谢你的关照`。让大家都知道你对他们花时间免费提供帮助心存感激。
-坦白说，这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）
+坦白说，这一点并没有比使用清晰、正确、精准且合乎语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）
然而，如果你有一串的问题待解决，客气一点肯定会增加你得到有用回应的机会。
@@ -436,10 +438,9 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
## 如何解读答案
-
### RTFM 和 STFW：如何知道你已完全搞砸了
-有一个古老而神圣的传统：如果你收到`RTFM （Read The Fucking Manual）`的回应，回答者认为你**应该去读他妈的手册**。当然，基本上他是对的，你应该去读一读。
+有一个古老而神圣的传统：如果你收到`RTFM（Read The Fucking Manual）`的回应，回答者认为你**应该去读他妈的手册**。当然，基本上他是对的，你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到`STFW（Search The Fucking Web）`的回应，回答者认为你**应该到他妈的网上搜索**。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 **[Google 是你的朋友](http://lmgtfy.com/)**！）
@@ -460,13 +461,13 @@ RTFM 有一个年轻的亲戚。如果你收到`STFW（Search The Fucking Web）
### 处理无礼的回应
-很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。
+很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直截了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。
如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这**没有**发生而你却发火了，那么你发火对象的言语可能在黑客社区中看起来是正常的，而**你**将被视为有错的一方，这将伤害到你获取信息或帮助的机会。
另一方面，你偶尔真的会碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击，用犀利的语言将其驳得体无完肤都是可以接受的。然而，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人，避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。
-（有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症，缺少用于润滑人类社会**正常**交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们**喜欢**我们现在这个样子，并且通常对病患标记都有站得住脚的怀疑）。
+（有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症，缺少用于润滑人类社会**正常**交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们**喜欢**我们现在这个样子，并且通常对病患标记都有站得住脚的怀疑。）
Jeff Bigler 的观察总结和这个相关也值得一读 (**[tact filters](http://www.mit.edu/~jcb/tact.html)**)。
@@ -640,25 +641,25 @@ Jeff Bigler 的观察总结和这个相关也值得一读 (**[tact filters](http
## 如何更好地回答问题
-**态度和善一点**。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。
+**态度和善一点。**问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。
-**对初犯者私下回复**。对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。
+**对初犯者私下回复。**对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。
-**如果你不确定，一定要说出来**！一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。
+**如果你不确定，一定要说出来！**一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。
-**如果帮不了忙，也别妨碍他**。不要在实际步骤上开玩笑，那样也许会毁了使用者的设置 —— 有些可怜的呆瓜会把它当成真的指令。
+**如果帮不了忙，也别妨碍他。**不要在实际步骤上开玩笑，那样也许会毁了使用者的设置 —— 有些可怜的呆瓜会把它当成真的指令。
-**试探性的反问以引出更多的细节**。如果你做得好，提问者可以学到点东西 —— 你也可以。试试将蠢问题转变成好问题，别忘了我们都曾是新手。
+**试探性的反问以引出更多的细节。**如果你做得好，提问者可以学到点东西 —— 你也可以。试试将蠢问题转变成好问题，别忘了我们都曾是新手。
-尽管对那些懒虫抱怨一声 RTFM 是正当的，能指出文件的位置（即使只是建议个 Google 搜索关键词）会更好。
+尽管对那些懒虫抱怨一声 RTFM 是正当的，但能指出文件的位置（即使只是建议个 Google 搜索关键词）会更好。
-**如果你决定回答，就请给出好的答案**。当别人正在用错误的工具或方法时别建议笨拙的权宜之计（workaround），应推荐更好的工具，重新界定问题。
+**如果你决定回答，就请给出好的答案。**当别人正在用错误的工具或方法时别建议笨拙的权宜之计（workaround），应推荐更好的工具，重新界定问题。
-**正面的回答问题**！如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 `试试看 A 或是 B` 或者 `试试 X 、 Y 、 Z 、 A 、 B 、 C` 并附上一个链接一点用都没有。
+**正面的回答问题！**如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 `试试看 A 或是 B` 或者 `试试 X 、 Y 、 Z 、 A 、 B 、 C` 并附上一个链接一点用都没有。
-**帮助你的社区从问题中学习**。当回复一个好问题时，问问自己`如何修改相关文件或常见问题文件以免再次解答同样的问题？`，接着再向文件维护者发一份补丁。
+**帮助你的社区从问题中学习。**当回复一个好问题时，问问自己`如何修改相关文件或常见问题文件以免再次解答同样的问题？`，接着再向文件维护者发一份补丁。
-如果你是在研究一番后才做出的回答，**展现你的技巧而不是直接端出结果**。毕竟`授人以鱼不如授人以渔`。
+如果你在研究一番后才作出了回答，**展现你的技巧而不是直接端出结果**。毕竟`授人以鱼不如授人以渔`。
## 相关资源
@@ -667,4 +668,5 @@ Jeff Bigler 的观察总结和这个相关也值得一读 (**[tact filters](http
当你发布软件或补丁时，试着按[软件发布实践](http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html)操作。
## 鸣谢
+
Evelyn Mitchel 贡献了一些愚蠢问题例子并启发了编写`如何更好地回答问题`这一节， Mikhail Ramendik 贡献了一些特别有价值的建议和改进。