[po] auto sync bot

zhsj · zhsj · commit 8a2784f2450a · 2019-04-03T22:24:49.000+08:00
diff --git a/c-api/init.po b/c-api/init.po
@@ -6,6 +6,7 @@
 # Translators:
 # Freesand Leo <yuqinju@163.com>, 2019
 # Trim21 <i@trim21.me>, 2019
+# Zombie110year <zombie110year@gmail.com>, 2019
 # 
 #, fuzzy
 msgid ""
@@ -14,7 +15,7 @@ msgstr ""
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2019-04-02 11:41+0900\n"
 "PO-Revision-Date: 2017-02-16 17:36+0000\n"
-"Last-Translator: Trim21 <i@trim21.me>, 2019\n"
+"Last-Translator: Zombie110year <zombie110year@gmail.com>, 2019\n"
 "Language-Team: Chinese (China) (https://www.transifex.com/python-doc/teams/5390/zh_CN/)\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
@@ -1750,7 +1751,7 @@ msgstr ""
 
 #: ../../c-api/init.rst:1494
 msgid "Methods"
-msgstr ""
+msgstr "方法"
 
 #: ../../c-api/init.rst:1496
 msgid ""
diff --git a/faq/design.po b/faq/design.po
@@ -217,7 +217,7 @@ msgid ""
 msgstr ""
 "其次，这意味着如果要显式引用或从特定类调用该方法，不需要特殊语法。 在 C++ 中，如果你想使用在派生类中重写基类中的方法，你必须使用 ``::`` "
 "运算符 -- 在 Python 中你可以编写 ``baseclass.methodname(self, <argument list>)``。 这对于 "
-":meth:`__init__` 方法特别有用，通常在其中派生类方法想要扩展同名的基类方法，而必须以某种方式调用基类方法时。"
+":meth:`__init__` 方法非常有用，特别是在派生类方法想要扩展同名的基类方法，而必须以某种方式调用基类方法时。"
 
 #: ../../faq/design.rst:134
 msgid ""
@@ -266,7 +266,7 @@ msgid ""
 "The error is a simple typo: ``x = 0``, which assigns 0 to the variable "
 "``x``, was written while the comparison ``x == 0`` is certainly what was "
 "intended."
-msgstr ""
+msgstr "错误是一个简单的错字：``x = 0``，将0赋给变量``x``，而比较``x == 0``肯定是可以预期的。"
 
 #: ../../faq/design.rst:183
 msgid ""
@@ -276,6 +276,8 @@ msgid ""
 "proper meaning to a human reader who has not yet been introduced to the "
 "construct."
 msgstr ""
+"已经有许多替代方案提案。 "
+"大多数是黑客提交的，目的是少打一些字，但使用任意或隐含的语法或关键词，并不符合语言变更提案的简单标准：它应该直观地向尚未被介绍到这一概念的人类读者提供正确的含义。"
 
 #: ../../faq/design.rst:188
 msgid ""
@@ -284,12 +286,14 @@ msgid ""
 "assignment in expression construct much; it's only newcomers who express a "
 "strong desire to add this to the language."
 msgstr ""
+"一个有趣的现象是，大多数有经验的Python程序员都认识到``while True``的习惯用法，也不太在意是否能在表达式构造中赋值; "
+"只有新人表达了强烈的愿望希望将其添加到语言中。"
 
 #: ../../faq/design.rst:193
 msgid ""
 "There's an alternative way of spelling this that seems attractive but is "
 "generally less robust than the \"while True\" solution::"
-msgstr ""
+msgstr "有一种替代的拼写方式看起来很有吸引力，但通常不如\"while True\"解决方案可靠："
 
 #: ../../faq/design.rst:201
 msgid ""
@@ -298,23 +302,27 @@ msgid ""
 " you have to remember to change two places in your program -- the second "
 "occurrence is hidden at the bottom of the loop."
 msgstr ""
+"问题在于，如果你改变主意（例如你想把它改成``sys.stdin.readline()``），如何知道下一行。你必须记住改变程序中的两个地方 -- "
+"第二次出现隐藏在循环的底部。"
 
 #: ../../faq/design.rst:206
 msgid ""
 "The best approach is to use iterators, making it possible to loop through "
 "objects using the ``for`` statement.  For example, :term:`file objects <file"
 " object>` support the iterator protocol, so you can write simply::"
 msgstr ""
+"最好的方法是使用迭代器，使用``for``语句循环遍历对象。 例如，:term:`file objects ` <file object> ` "
+"支持迭代器协议， 因此可以简单地写为："
 
 #: ../../faq/design.rst:216
 msgid ""
 "Why does Python use methods for some functionality (e.g. list.index()) but "
 "functions for other (e.g. len(list))?"
-msgstr ""
+msgstr "为什么Python对某些功能(例如list.index()使用方法来实现，而其他功能(例如len(List)使用函数实现？"
 
 #: ../../faq/design.rst:218
 msgid "As Guido said:"
-msgstr ""
+msgstr "正如Guido所说："
 
 #: ../../faq/design.rst:220
 msgid ""
@@ -324,6 +332,8 @@ msgid ""
 "problem. Compare the easy with which we rewrite a formula like x*(a+b) into "
 "x*a + x*b to the clumsiness of doing the same thing using a raw OO notation."
 msgstr ""
+"(a) 对于某些操作，前缀表示法比后缀更容易阅读 -- "
+"前缀（和中缀！）运算在数学中有着悠久的传统，就像在视觉上帮助数学家思考问题的记法。比较一下我们将x*（a+b）这样的公式改写为x*a+x*b的容易程度，以及使用原始OO符号做相同事情的笨拙程度。"
 
 #: ../../faq/design.rst:227
 msgid ""
@@ -336,15 +346,18 @@ msgid ""
 "implementing a mapping has a get() or keys() method, or something that isn't"
 " a file has a write() method."
 msgstr ""
+"(b)  "
+"当读到写有len(X)的代码时，就知道它要求的是某件东西的长度。这告诉我们两件事：结果是一个整数，参数是某种容器。相反，当阅读x.len()时，必须已经知道x是某种实现接口的容器，或者是从具有标准len()的类继承的容器。当没有实现映射的类有get()或key()方法，或者不是文件的类有write()方法时，我们偶尔会感到困惑。"
 
 #: ../../faq/design.rst:254
 msgid ""
 "https://mail.python.org/pipermail/python-3000/2006-November/004643.html"
 msgstr ""
+"https://mail.python.org/pipermail/python-3000/2006-November/004643.html"
 
 #: ../../faq/design.rst:240
 msgid "Why is join() a string method instead of a list or tuple method?"
-msgstr ""
+msgstr "为什么 join()是一个字符串方法而不是列表或元组方法？"
 
 #: ../../faq/design.rst:242
 msgid ""
@@ -354,14 +367,16 @@ msgid ""
 "methods have been widely accepted, but the one which appears to make some "
 "programmers feel uncomfortable is::"
 msgstr ""
+"从Python "
+"1.6开始，字符串变得更像其他标准类型，当添加方法时，这些方法提供的功能与始终使用String模块的函数时提供的功能相同。这些新方法中的大多数已被广泛接受，但似乎让一些程序员感到不舒服的一种方法是："
 
 #: ../../faq/design.rst:250
 msgid "which gives the result::"
-msgstr ""
+msgstr "给出结果::"
 
 #: ../../faq/design.rst:254
 msgid "There are two common arguments against this usage."
-msgstr ""
+msgstr "反对这种用法有两个常见的论点。"
 
 #: ../../faq/design.rst:256
 msgid ""
@@ -371,6 +386,8 @@ msgid ""
 " on names bound to strings there is no logical reason to make them "
 "unavailable on literals."
 msgstr ""
+"第一条是这样的：“使用字符串文本(String "
+"Constant)的方法看起来真的很难看”，答案是也许吧，但是字符串文本只是一个固定值。如果在绑定到字符串的名称上允许使用这些方法，则没有逻辑上的理由使其在文字上不可用。"
 
 #: ../../faq/design.rst:262
 msgid ""
@@ -380,12 +397,14 @@ msgid ""
 ":meth:`~str.split` as a string method, since in that case it is easy to see "
 "that ::"
 msgstr ""
+"第二个异议通常是这样的：“我实际上是在告诉序列使用字符串常量将其成员连接在一起”。遗憾的是并非如此。出于某种原因，把:meth:`~str.split`"
+" 作为一个字符串方法似乎要容易得多，因为在这种情况下，很容易看到："
 
 #: ../../faq/design.rst:269
 msgid ""
 "is an instruction to a string literal to return the substrings delimited by "
 "the given separator (or, by default, arbitrary runs of white space)."
-msgstr ""
+msgstr "是对字符串文本的指令，用于返回由给定分隔符分隔的子字符串(或在默认情况下，返回任意空格)。"
 
 #: ../../faq/design.rst:272
 msgid ""
diff --git a/howto/functional.po b/howto/functional.po
@@ -10,6 +10,7 @@
 # Kder <kder@live.cn>, 2018
 # Freesand Leo <yuqinju@163.com>, 2018
 # yuxin wang <wangyuxinwhy@gmail.com>, 2019
+# chen_chao <wenbushi@gmail.com>, 2019
 # 
 #, fuzzy
 msgid ""
@@ -18,7 +19,7 @@ msgstr ""
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2019-01-01 10:14+0900\n"
 "PO-Revision-Date: 2017-02-16 17:44+0000\n"
-"Last-Translator: yuxin wang <wangyuxinwhy@gmail.com>, 2019\n"
+"Last-Translator: chen_chao <wenbushi@gmail.com>, 2019\n"
 "Language-Team: Chinese (China) (https://www.transifex.com/python-doc/teams/5390/zh_CN/)\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
@@ -105,6 +106,8 @@ msgid ""
 "and Python are languages that support object-oriented programming, but don't"
 " force the use of object-oriented features."
 msgstr ""
+"**面向对象**程序会操作一组对象。 对象拥有内部状态，并能够以某种方式支持请求和修改这个内部状态的方法。Smalltalk 和 JAVA "
+"都是面向对象的语言。 C++ 和 Python 支持面向对象编程，但并不强制使用面向对象特性。"
 
 #: ../../howto/functional.rst:41
 msgid ""
@@ -114,6 +117,8 @@ msgid ""
 "known functional languages include the ML family (Standard ML, OCaml, and "
 "other variants) and Haskell."
 msgstr ""
+"**函数式**编程则将一个问题分解成一系列函数。 理想情况下，函数只接受输入并输出结果，对一个给定的输入也不会有影响输出的内部状态。著名的函数式语言有 "
+"ML 家族（Standard ML，Ocaml以及其他变种）和 Haskell。"
 
 #: ../../howto/functional.rst:47
 msgid ""
@@ -127,6 +132,10 @@ msgid ""
 " GUI might be object-oriented while the processing logic is procedural or "
 "functional, for example."
 msgstr ""
+"一些语言的设计者选择强调一种特定的编程方式。 这通常会让以不同的方式来编写程序变得困难。其他多范式语言则支持几种不同的编程方式。Lisp，C++ 和 "
+"Python "
+"都是多范式语言；使用这些语言，你可以编写主要为过程式，面向对象或者函数式的程序和函数库。在大型程序中，不同的部分可能会采用不同的方式编写；比如 GUI "
+"可能是面向对象的而处理逻辑则是过程式或者函数式。"
 
 #: ../../howto/functional.rst:58
 msgid ""
@@ -138,6 +147,7 @@ msgid ""
 "Avoiding side effects means not using data structures that get updated as a "
 "program runs; every function's output must only depend on its input."
 msgstr ""
+"在函数式程序里，输入流经一系列函数。每个函数接受输入并输出结果。函数式风格反对使用带有副作用的函数，这些副作用会修改内部状态，或者引起一些无法体现在函数的返回值中的变化。完全不产生副作用的函数被称作“纯函数”。消除副作用意味着不能使用随程序运行而更新的数据结构；每个函数的输出必须只依赖于输入。"
 
 #: ../../howto/functional.rst:66
 msgid ""
@@ -149,6 +159,9 @@ msgid ""
 "called for their side effects of sending some text to the screen or pausing "
 "execution for a second."
 msgstr ""
+"一些语言对纯洁性要求非常严格，以至于没有像 ``a=3`` 或 ``c = a + b`` 这样的赋值表达式，但是完全消除副作用非常困难。 "
+"比如，显示在屏幕上或者写到磁盘文件中都是副作用。举个例子，在 Python 里，调用函数 :func:`print` 或者 "
+"：func：`time.sleep` 并不会返回有用的结果；它们的用途只在于副作用，向屏幕发送一段文字或暂停一秒钟。"
 
 #: ../../howto/functional.rst:74
 msgid ""
@@ -159,6 +172,8 @@ msgid ""
 "assignments to local variables, but won't modify global variables or have "
 "other side effects."
 msgstr ""
+"函数式风格的 Python 程序并不会极端到消除所有 I/O "
+"或者赋值的程度；相反，他们会提供像函数式一样的接口，但会在内部使用非函数式的特性。比如，函数的实现仍然会使用局部变量，但不会修改全局变量或者有其他副作用。"
 
 #: ../../howto/functional.rst:80
 msgid ""
@@ -171,39 +186,41 @@ msgid ""
 "approaches by writing functions that take and return instances representing "
 "objects in your application (e-mail messages, transactions, etc.)."
 msgstr ""
+"函数式编程可以被认为是面向对象编程的对立面。对象就像是小胶囊，包裹着内部状态和随之而来的能让你修改这个内部状态的一组调用方法，以及由正确的状态变化所构成的程序。函数式编程希望尽可能地消除状态变化，只和流经函数的数据打交道。在"
+" Python 里你可以把两种编程方式结合起来，在你的应用（电子邮件信息，事务处理）中编写接受和返回对象实例的函数。"
 
 #: ../../howto/functional.rst:89
 msgid ""
 "Functional design may seem like an odd constraint to work under.  Why should"
 " you avoid objects and side effects?  There are theoretical and practical "
 "advantages to the functional style:"
-msgstr ""
+msgstr "函数式设计在工作中看起来是个奇怪的约束。为什么你要消除对象和副作用呢？不过函数式风格有其理论和实践上的优点："
 
 #: ../../howto/functional.rst:93
 msgid "Formal provability."
-msgstr ""
+msgstr "形式证明。"
 
 #: ../../howto/functional.rst:94
 msgid "Modularity."
-msgstr ""
+msgstr "模块化。"
 
 #: ../../howto/functional.rst:95
 msgid "Composability."
-msgstr ""
+msgstr "组合性。"
 
 #: ../../howto/functional.rst:96
 msgid "Ease of debugging and testing."
-msgstr ""
+msgstr "易于调试和测试。"
 
 #: ../../howto/functional.rst:100
 msgid "Formal provability"
-msgstr ""
+msgstr "形式证明"
 
 #: ../../howto/functional.rst:102
 msgid ""
 "A theoretical benefit is that it's easier to construct a mathematical proof "
 "that a functional program is correct."
-msgstr ""
+msgstr "一个理论上的优点是，构造数学证明来说明函数式程序是正确的相对更容易些。"
 
 #: ../../howto/functional.rst:105
 msgid ""
@@ -214,6 +231,7 @@ msgid ""
 "looks right; the goal is instead a rigorous proof that a program produces "
 "the right result for all possible inputs."
 msgstr ""
+"很长时间，研究者们对寻找证明程序正确的数学方法都很感兴趣。这和通过大量输入来测试，并得出程序的输出基本正确，或者阅读一个程序的源代码然后得出代码看起来没问题不同；相反，这里的目标是一个严格的证明，证明程序对所有可能的输入都能给出正确的结果。"
 
 #: ../../howto/functional.rst:112
 msgid ""
@@ -225,14 +243,16 @@ msgid ""
 "This continues until you reach the end of the program, at which point the "
 "invariants should match the desired conditions on the program's output."
 msgstr ""
+"证明程序正确性所用到的技术是写出**不变量**，也就是对于输入数据和程序中的变量永远为真的特性。然后对每行代码，你说明这行代码执行前的不变量 X 和 Y"
+" 以及执行后稍有不同的不变量 X' 和 Y' 为真。如此一直到程序结束，这时候在程序的输出上，不变量应该会与期望的状态一致。"
 
 #: ../../howto/functional.rst:120
 msgid ""
 "Functional programming's avoidance of assignments arose because assignments "
 "are difficult to handle with this technique; assignments can break "
 "invariants that were true before the assignment without producing any new "
 "invariants that can be propagated onward."
-msgstr ""
+msgstr "函数式编程之所以要消除赋值，是因为赋值在这个技术中难以处理；赋值可能会破坏赋值前为真的不变量，却并不产生任何可以传递下去的新的不变量。"
 
 #: ../../howto/functional.rst:125
 msgid ""
@@ -245,10 +265,14 @@ msgid ""
 "the question of verifying the proof; maybe there's an error in it, and you "
 "wrongly believe you've proved the program correct."
 msgstr ""
+"不幸的是，证明程序的正确性很大程度上是经验性质的，而且和 Python "
+"软件无关。即使是微不足道的程序都需要几页长的证明；一个中等复杂的程序的正确性证明会非常庞大，而且，极少甚至没有你日常所使用的程序（Python "
+"解释器，XML "
+"解析器，浏览器）的正确性能够被证明。即使你写出或者生成一个证明，验证证明也会是一个问题；里面可能出了差错，而你错误地相信你证明了程序的正确性。"
 
 #: ../../howto/functional.rst:136
 msgid "Modularity"
-msgstr ""
+msgstr "模块化"
 
 #: ../../howto/functional.rst:138
 msgid ""
@@ -258,14 +282,15 @@ msgid ""
 "thing than a large function that performs a complicated transformation.  "
 "Small functions are also easier to read and to check for errors."
 msgstr ""
+"函数式编程的一个更实用的优点是，它强制你把问题分解成小的方面。因此程序会更加模块化。相对于一个进行了复杂变换的大型函数，一个小的函数更明确，更易于编写。小函数也更易于阅读和检查错误。"
 
 #: ../../howto/functional.rst:146
 msgid "Ease of debugging and testing"
-msgstr ""
+msgstr "易于调试和测试"
 
 #: ../../howto/functional.rst:148
 msgid "Testing and debugging a functional-style program is easier."
-msgstr ""
+msgstr "测试和调试函数式程序相对来说更容易。"
 
 #: ../../howto/functional.rst:150
 msgid ""
@@ -275,6 +300,7 @@ msgid ""
 "intermediate inputs and outputs to quickly isolate the function that's "
 "responsible for a bug."
 msgstr ""
+"调试很简单是因为函数通常都很小而且清晰明确。当程序无法工作的时候，每个函数都是一个可以检查数据是否正确的接入点。你可以通过查看中间输入和输出迅速找到出错的函数。"
 
 #: ../../howto/functional.rst:155
 msgid ""
@@ -283,6 +309,7 @@ msgid ""
 "before running a test; instead you only have to synthesize the right input "
 "and then check that the output matches expectations."
 msgstr ""
+"测试更容易是因为每个函数都是单元测试的潜在目标。在执行测试前，函数并不依赖于需要重现的系统状态；相反，你只需要给出正确的输入，然后检查输出是否和期望的结果一致。"
 
 #: ../../howto/functional.rst:162
 msgid "Composability"
diff --git a/library/nntplib.po b/library/nntplib.po
@@ -3,13 +3,17 @@
 # This file is distributed under the same license as the Python package.
 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
 # 
+# Translators:
+# Zombie110year <zombie110year@gmail.com>, 2019
+# 
 #, fuzzy
 msgid ""
 msgstr ""
 "Project-Id-Version: Python 3.7\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2019-01-03 10:20+0900\n"
 "PO-Revision-Date: 2017-02-16 23:20+0000\n"
+"Last-Translator: Zombie110year <zombie110year@gmail.com>, 2019\n"
 "Language-Team: Chinese (China) (https://www.transifex.com/python-doc/teams/5390/zh_CN/)\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
@@ -164,7 +168,7 @@ msgstr ""
 
 #: ../../library/nntplib.rst:174
 msgid "Methods"
-msgstr ""
+msgstr "方法"
 
 #: ../../library/nntplib.rst:176
 msgid ""
diff --git a/library/pathlib.po b/library/pathlib.po
