Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit a3c7245

Browse files
committed
[po] auto sync bot
1 parent f5bc0c1 commit a3c7245

9 files changed

Lines changed: 233 additions & 116 deletions

File tree

distutils/setupscript.po

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -6,8 +6,8 @@
66
# Translators:
77
# ww song <[email protected]>, 2018
88
# 叶浚安 <[email protected]>, 2019
9-
# Meng Du <[email protected]>, 2019
109
# Freesand Leo <[email protected]>, 2019
10+
# Meng Du <[email protected]>, 2019
1111
#
1212
#, fuzzy
1313
msgid ""
@@ -16,7 +16,7 @@ msgstr ""
1616
"Report-Msgid-Bugs-To: \n"
1717
"POT-Creation-Date: 2019-01-31 10:32+0900\n"
1818
"PO-Revision-Date: 2017-02-16 17:41+0000\n"
19-
"Last-Translator: Freesand Leo <yuqinju@163.com>, 2019\n"
19+
"Last-Translator: Meng Du <alphanow@gmail.com>, 2019\n"
2020
"Language-Team: Chinese (China) (https://www.transifex.com/python-doc/teams/5390/zh_CN/)\n"
2121
"MIME-Version: 1.0\n"
2222
"Content-Type: text/plain; charset=UTF-8\n"
@@ -388,7 +388,7 @@ msgstr ""
388388

389389
#: ../../distutils/setupscript.rst:335
390390
msgid "Other options"
391-
msgstr ""
391+
msgstr "其他选项"
392392

393393
#: ../../distutils/setupscript.rst:337
394394
msgid ""

howto/cporting.po

Lines changed: 52 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ msgstr ""
2525

2626
#: ../../howto/cporting.rst:7
2727
msgid "Porting Extension Modules to Python 3"
28-
msgstr ""
28+
msgstr "将扩展模块移植到 Python 3"
2929

3030
#: ../../howto/cporting.rst:0
3131
msgid "author"
@@ -47,36 +47,39 @@ msgid ""
4747
" obvious on the C level. This document endeavors to document "
4848
"incompatibilities and how they can be worked around."
4949
msgstr ""
50+
"尽管更改 C-API 并不是 Python 3 的目标之一,但许多 Python 级别的更改使得 Python 2 的 API "
51+
"无法完整实现。实际上,一些变化如 :func:`int` 和 :func:`long` 的统一在 C "
52+
"级别更明显。本文档致力于记录不兼容性以及如何解决这些问题。"
5053

5154
#: ../../howto/cporting.rst:23
5255
msgid "Conditional compilation"
53-
msgstr ""
56+
msgstr "条件编译"
5457

5558
#: ../../howto/cporting.rst:25
5659
msgid ""
5760
"The easiest way to compile only some code for Python 3 is to check if "
5861
":c:macro:`PY_MAJOR_VERSION` is greater than or equal to 3. ::"
59-
msgstr ""
62+
msgstr "仅编译 Python 3 的一些代码的最简单方法是检查 :c:macro:`PY_MAJOR_VERSION` 是否大于或等于3。 ::"
6063

6164
#: ../../howto/cporting.rst:32
6265
msgid ""
6366
"API functions that are not present can be aliased to their equivalents "
6467
"within conditional blocks."
65-
msgstr ""
68+
msgstr "不存在的 API 函数可以在条件块中别名为它们的等价物。"
6669

6770
#: ../../howto/cporting.rst:37
6871
msgid "Changes to Object APIs"
69-
msgstr ""
72+
msgstr "对象API的更改"
7073

7174
#: ../../howto/cporting.rst:39
7275
msgid ""
7376
"Python 3 merged together some types with similar functions while cleanly "
7477
"separating others."
75-
msgstr ""
78+
msgstr "Python 3 将一些具有类似功能的类型合并在一起,同时干净地分离了其他类型。"
7679

7780
#: ../../howto/cporting.rst:44
7881
msgid "str/unicode Unification"
79-
msgstr ""
82+
msgstr "str/unicode 统一"
8083

8184
#: ../../howto/cporting.rst:46
8285
msgid ""
@@ -92,10 +95,18 @@ msgid ""
9295
"Python 2. The following example shows best practices with regards to "
9396
":c:type:`PyUnicode`, :c:type:`PyString`, and :c:type:`PyBytes`. ::"
9497
msgstr ""
98+
"Python 3 的 :func:`str` 类型相当于 Python 2 的 :func:`unicode` ; C函数被称为 "
99+
"``PyUnicode_*`` 。旧的 8 位字符串类型变为 :func:`bytes` ,其中 C 函数称为 ``PyBytes_*`` 。 "
100+
"Python 2.6 及更高版本提供了一个兼容性头文件 :file:`bytesobject.h` ,将 ``PyBytes`` 名称映射到 "
101+
"``PyString`` 。 为了保持与 Python 3 的最佳兼容性, :c:type:`PyUnicode` 应该用于文本数据,并且 "
102+
":c:type:`PyBytes` 用于二进制数据。同样重要的是要记住 :c:type:`pyBytes` 和 Python 3中的 "
103+
":c:type:`PyUnicode` 不可互换,如 :c:type:`PyString` 和 :c:type:`PyUnicode` 在 Python"
104+
" 2 以下中示例显示了以下方面的最佳实践 :c:type:`PyUnicode` 、 :c:type:`PyString` 和 "
105+
":c:type:`PyBytes` 。::"
95106

96107
#: ../../howto/cporting.rst:95
97108
msgid "long/int Unification"
98-
msgstr ""
109+
msgstr "long/int 统一"
99110

100111
#: ../../howto/cporting.rst:97
101112
msgid ""
@@ -104,10 +115,13 @@ msgid ""
104115
"Python 2 was removed. In the C-API, ``PyInt_*`` functions are replaced by "
105116
"their ``PyLong_*`` equivalents."
106117
msgstr ""
118+
"Python 3 只有一个整数类型, :func:`int` 。但它实际上对应于Python 2 :func:`long` 类型 —— 删除了 "
119+
"Python 2 中使用的 :func:`int` 类型。在 C-API 中, ``PyInt_*`` 函数被它们等价的 ``PyLong_*`` "
120+
"替换。"
107121

108122
#: ../../howto/cporting.rst:104
109123
msgid "Module initialization and state"
110-
msgstr ""
124+
msgstr "模块初始化和状态"
111125

112126
#: ../../howto/cporting.rst:106
113127
msgid ""
@@ -117,10 +131,13 @@ msgid ""
117131
"correctly in both Python 2 and Python 3 is tricky. The following simple "
118132
"example demonstrates how. ::"
119133
msgstr ""
134+
"Python 3 有一个改进的扩展模块初始化系统。(参见 :pep:`3121` "
135+
"。)而不是将模块状态存储在全局变量中,它们应该存储在特定于解释器的结构中。创建在 Python 2 和 Python 3 "
136+
"中正确运行的模块非常棘手。以下简单示例演示了如何操作。::"
120137

121138
#: ../../howto/cporting.rst:197
122139
msgid "CObject replaced with Capsule"
123-
msgstr ""
140+
msgstr "CObject 替换为 Capsule"
124141

125142
#: ../../howto/cporting.rst:199
126143
msgid ""
@@ -131,6 +148,10 @@ msgid ""
131148
"relied on undefined behavior in C. (For further reading on the rationale "
132149
"behind Capsules, please see :issue:`5630`.)"
133150
msgstr ""
151+
":c:type:`Capsule` 对象是在 Python 3.1 和 2.7 中引入的,用于替换 :c:type:`CObject` 。 "
152+
"CObject 是有用的,但是 :c:type:`CObject` API 是有问题的:它不允许区分有效的 CObject ,这导致不匹配的 "
153+
"CObject 使解释器崩溃,并且它的一些 API 依赖于 C 中的未定义行为。有关 Capsule 背后的基本原理的进一步阅读,请参阅 "
154+
":issue:`5630` 。)"
134155

135156
#: ../../howto/cporting.rst:206
136157
msgid ""
@@ -142,6 +163,10 @@ msgid ""
142163
"support both CObjects and Capsules. (Note that Python 3.0 is no longer "
143164
"supported, and it is not recommended for production use.)"
144165
msgstr ""
166+
"如果你当前正在使用 CObject ,并且想要迁移到 3.1 或更高版本,则需要切换到 Capsules 。 :c:type:`CObject` 在 "
167+
"3.1 和 2.7 中已弃用,在 Python 3.2 中已完全删除。如果你只支持 2.7 或 3.1 及以上,你可以简单地切换到 "
168+
":c:type:`Capsule` 。如果你需要支持 Python 3.0 或早于 2.7 的 Python 版本,则必须同时支持 CObject 和 "
169+
"Capsule 。(请注意,不再支持 Python 3.0 ,不建议将其用于生产用途。)"
145170

146171
#: ../../howto/cporting.rst:216
147172
msgid ""
@@ -151,6 +176,9 @@ msgid ""
151176
"automatically use Capsules in versions of Python with Capsules, and switch "
152177
"to CObjects when Capsules are unavailable."
153178
msgstr ""
179+
"以下示例头文件 :file:`capsulethunk.h` 可以为你解决问题。只需针对 :c:type:`Capsule` API "
180+
"编写代码,并在以下文件后包含此头文件 :file:`Python.h` 。你的代码将自动在带有 Capsule 的 Python 版本中使用 "
181+
"Capsules ,并在 Capsule 不可用时切换到 CObjects 。"
154182

155183
#: ../../howto/cporting.rst:223
156184
msgid ""
@@ -160,21 +188,26 @@ msgid ""
160188
":file:`capsulethunk.h` behave slightly differently from real Capsules. "
161189
"Specifically:"
162190
msgstr ""
191+
":file:`capsulethunk.h` 使用 CObject 模拟 Capsules 。 但是, :c:type:`CObject` "
192+
"没有提供存储胶囊的“名称”的地方。因此,模拟 :c:type:`Capsule` 对象由 :file:`capsulethunk.h` "
193+
"创建,其行为与真实 Capsule 略有不同。特别地:"
163194

164195
#: ../../howto/cporting.rst:228
165196
msgid "The name parameter passed in to :c:func:`PyCapsule_New` is ignored."
166-
msgstr ""
197+
msgstr "传递给 :c:func:`PyCapsule_New` 的 name 参数被忽略。"
167198

168199
#: ../../howto/cporting.rst:230
169200
msgid ""
170201
"The name parameter passed in to :c:func:`PyCapsule_IsValid` and "
171202
":c:func:`PyCapsule_GetPointer` is ignored, and no error checking of the name"
172203
" is performed."
173204
msgstr ""
205+
"传入以下命令的 name 参数 :c:func:`PyCapsule_IsValid` 和 :c:func:`PyCapsule_GetPointer`"
206+
" 被忽略,并且不执行错误检查。"
174207

175208
#: ../../howto/cporting.rst:234
176209
msgid ":c:func:`PyCapsule_GetName` always returns NULL."
177-
msgstr ""
210+
msgstr ":c:func:`PyCapsule_GetName` 总是返回 NULL 。"
178211

179212
#: ../../howto/cporting.rst:236
180213
msgid ""
@@ -184,21 +217,27 @@ msgid ""
184217
"If this is inconvenient, feel free to modify your local copy as you see "
185218
"fit.)"
186219
msgstr ""
220+
":c:func:`PyCapsule_SetName` 总是引发异常并返回失败。(由于无法在 CObject 中存储名称,因此 "
221+
":c:func:`PyCapsule_SetName` 的明显失败被认为优于静默失败。如果这样不方便,请随意根据需要修改本地副本。)"
187222

188223
#: ../../howto/cporting.rst:243
189224
msgid ""
190225
"You can find :file:`capsulethunk.h` in the Python source distribution as "
191226
":source:`Doc/includes/capsulethunk.h`. We also include it here for your "
192227
"convenience:"
193228
msgstr ""
229+
"你可以在 Python 源代码分发中的 :source:`Doc/includes/capsulethunk.h` 找到 "
230+
":file:`capsulethunk.h` 。为方便起见,我们还将其包含在此处:"
194231

195232
#: ../../howto/cporting.rst:252
196233
msgid "Other options"
197-
msgstr ""
234+
msgstr "其他选项"
198235

199236
#: ../../howto/cporting.rst:254
200237
msgid ""
201238
"If you are writing a new extension module, you might consider `Cython "
202239
"<http://cython.org/>`_. It translates a Python-like language to C. The "
203240
"extension modules it creates are compatible with Python 3 and Python 2."
204241
msgstr ""
242+
"如果你正在编写新的扩展模块,你可能会考虑 `Cython <http://cython.org/>`_ 。 它将类似 Python 的语言转换为 C "
243+
"。它创建的扩展模块与 Python 3 和 Python 2 兼容。"

howto/instrumentation.po

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,7 @@
77
# Fred <[email protected]>, 2018
88
# Chengeng Ning <[email protected]>, 2018
99
# 非法操作 <[email protected]>, 2019
10+
# Meng Du <[email protected]>, 2019
1011
#
1112
#, fuzzy
1213
msgid ""
@@ -15,7 +16,7 @@ msgstr ""
1516
"Report-Msgid-Bugs-To: \n"
1617
"POT-Creation-Date: 2019-01-01 10:14+0900\n"
1718
"PO-Revision-Date: 2017-02-16 17:45+0000\n"
18-
"Last-Translator: 非法操作 <ultrahe@gmail.com>, 2019\n"
19+
"Last-Translator: Meng Du <alphanow@gmail.com>, 2019\n"
1920
"Language-Team: Chinese (China) (https://www.transifex.com/python-doc/teams/5390/zh_CN/)\n"
2021
"MIME-Version: 1.0\n"
2122
"Content-Type: text/plain; charset=UTF-8\n"
@@ -33,11 +34,11 @@ msgstr "作者"
3334

3435
#: ../../howto/instrumentation.rst:9
3536
msgid "David Malcolm"
36-
msgstr ""
37+
msgstr "David Malcolm"
3738

3839
#: ../../howto/instrumentation.rst:10
3940
msgid "Łukasz Langa"
40-
msgstr ""
41+
msgstr "Łukasz Langa"
4142

4243
#: ../../howto/instrumentation.rst:12
4344
msgid ""

howto/sockets.po

Lines changed: 25 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -477,6 +477,8 @@ msgid ""
477477
"calls, in much the same ways. It's just that, if you do it right, your app "
478478
"will be almost inside-out."
479479
msgstr ""
480+
"如果你已理解上述内容,那么你已经了解了使用套接字的机制所需了解的大部分内容。你仍将以相同的方式使用相同的函数调用。 "
481+
"只是,如果你做得对,你的应用程序几乎是由内到外的。"
480482

481483
#: ../../howto/sockets.rst:320
482484
msgid ""
@@ -487,6 +489,9 @@ msgid ""
487489
"the exact same idea. You do this after creating the socket, but before using"
488490
" it. (Actually, if you're nuts, you can switch back and forth.)"
489491
msgstr ""
492+
"在 Python 中,使用 ``socket.setblocking(0)`` 使其无阻塞。 在 C 中,它更复杂,(一方面,你需要在 BSD 风格的 "
493+
"``O_NONBLOCK`` 和几乎无法区分的 Posix 风格的 ``O_NDELAY`` 之间做出选择,这与 ``TCP_NODELAY`` "
494+
"完全不同。) 。但这是完全相同的想法。你可以在创建套接字之后但在使用之前执行此操作。 (实际上,如果你疯了,你可以来回切换。)"
490495

491496
#: ../../howto/sockets.rst:327
492497
msgid ""
@@ -497,6 +502,9 @@ msgid ""
497502
"will grow large, buggy and suck CPU. So let's skip the brain-dead solutions "
498503
"and do it right."
499504
msgstr ""
505+
"主要的机制差异是 ``send`` 、 ``recv`` 、 ``connect`` 和 ``accept`` 可以在没有做任何事情的情况下返回。 "
506+
"你(当然)有很多选择。你可以检查返回代码和错误代码,通常会让自己发疯。如果你不相信我,请尝试一下。你的应用程序将变得越来越大、越来越 Bug 、吸干 "
507+
"CPU。因此,让我们跳过脑死亡的解决方案并做正确的事。"
500508

501509
#: ../../howto/sockets.rst:334
502510
msgid "Use ``select``."
@@ -508,6 +516,8 @@ msgid ""
508516
"but it's close enough to the C version that if you understand ``select`` in "
509517
"Python, you'll have little trouble with it in C::"
510518
msgstr ""
519+
"在 C 中,编码 ``select`` 相当复杂。 在 Python 中,它是很简单,但它与 C 版本足够接近,如果你在 Python 中理解 "
520+
"``select`` ,那么在 C 中你会几乎不会遇到麻烦::"
511521

512522
#: ../../howto/sockets.rst:347
513523
msgid ""
@@ -519,13 +529,16 @@ msgid ""
519529
"generally a sensible thing to do - give it a nice long timeout (say a "
520530
"minute) unless you have good reason to do otherwise."
521531
msgstr ""
532+
"你传递给 ``select`` "
533+
"三个列表:第一个包含你可能想要尝试读取的所有套接字;第二个是你可能想要尝试写入的所有套接字,以及要检查错误的最后一个(通常为空)。你应该注意,套接字可以进入多个列表。"
534+
" ``select`` 调用是阻塞的,但你可以给它一个超时。这通常是一件明智的事情 —— 给它一个很长的超时(比如一分钟),除非你有充分的理由不这样做。"
522535

523536
#: ../../howto/sockets.rst:355
524537
msgid ""
525538
"In return, you will get three lists. They contain the sockets that are "
526539
"actually readable, writable and in error. Each of these lists is a subset "
527540
"(possibly empty) of the corresponding list you passed in."
528-
msgstr ""
541+
msgstr "作为返回,你将获得三个列表。它们包含实际可读、可写和有错误的套接字。 这些列表中的每一个都是你传入的相应列表的子集(可能为空)。"
529542

530543
#: ../../howto/sockets.rst:359
531544
msgid ""
@@ -536,6 +549,9 @@ msgid ""
536549
"nothing. (Actually, any reasonably healthy socket will return as writable -"
537550
" it just means outbound network buffer space is available.)"
538551
msgstr ""
552+
"如果一个套接字在输出可读列表中,那么你可以像我们一样接近这个业务,那个套接字上的 ``recv`` 将返回 *一些内容* "
553+
"。可写列表的也相同,你将能够发送 *一些内容* 。 也许不是你想要的全部,但 *有些东西* 比没有东西更好。 "
554+
"(实际上,任何合理健康的套接字都将以可写方式返回 —— 它只是意味着出站网络缓冲区空间可用。)"
539555

540556
#: ../../howto/sockets.rst:366
541557
msgid ""
@@ -545,6 +561,9 @@ msgid ""
545561
"it in the potential_writers list. If it shows up in the writable list, you "
546562
"have a decent chance that it has connected."
547563
msgstr ""
564+
"如果你有一个“服务器”套接字,请将其放在 potential_readers 列表中。如果它出现在可读列表中,那么你的 ``accept`` "
565+
"(几乎肯定)会起作用。如果你已经创建了一个新的套接字 ``connect`` 其他人,请将它放在 potential_writers "
566+
"列表中。如果它出现在可写列表中,那么它有可能已连接。"
548567

549568
#: ../../howto/sockets.rst:372
550569
msgid ""
@@ -554,6 +573,8 @@ msgid ""
554573
" problem of determining whether the other end is done, or just busy with "
555574
"something else."
556575
msgstr ""
576+
"实际上,即使使用阻塞套接字, ``select`` 也很方便。这是确定是否阻塞的一种方法 —— "
577+
"当缓冲区中存在某些内容时,套接字返回为可读。然而,这仍然无助于确定另一端是否完成或者只是忙于其他事情的问题。"
557578

558579
#: ../../howto/sockets.rst:377
559580
msgid ""
@@ -563,3 +584,6 @@ msgid ""
563584
" differently on Windows. In fact, on Windows I usually use threads (which "
564585
"work very, very well) with my sockets."
565586
msgstr ""
587+
"**可移植性警告** :在 Unix 上, ``select`` 适用于套接字和文件。 不要在 Windows 上尝试。在 Windows 上, "
588+
"``select`` 仅适用于套接字。另请注意,在 C 中,许多更高级的套接字选项在 Windows 上的执行方式不同。事实上,在 Windows "
589+
"上我通常在使用我的套接字使用线程(非常非常好)。"

0 commit comments

Comments
 (0)