Merge branch '2022' into 4_session

contribute/governance/rfcs/0001_rfc_process.md

@@ -27,7 +27,7 @@ establishing a consistent and transparent path for making project-wide,
 technical decisions, all the stakeholders can be confident about the technical
 direction of the project.
 -->
-现在，Fuchsia 项目在项目级别的技术决定上并没有一个正式的工作流程。以我们目前的规模来说，这样的非正式性导致了不同的人在项目方向和如何组合系统上有着不同的看法。 通过建立这样一个一致且透明的项目标准， 所有的利益相关者都能够在项目的技术方向充满信息。
+现在，Fuchsia 项目在项目级别的技术决定上并没有一个正式的工作流程。以我们目前的规模来说，这样的非正式性导致了不同的人在项目方向和如何组合系统上有着不同的看法。 通过建立这样一个一致且透明的项目标准， 所有的利益相关者都能够在项目的技术方向充满信心。
 <!--
 ## Design
 -->
@@ -72,7 +72,7 @@ The following kinds of changes must use the RFC process:
    changing the set of supported languages impacts everyone who needs to debug
    and understand the system, even if not everyone uses the new language.
 -->
- * **制订项目政策。** 项目政策对系统有着广泛的影响，常常影响着项目贡献者。比如，修改支持的（编程）语言集，会影响需要调试和理解系统的人员，即使并不是所有的人都使用新语言。
+ * **制定项目政策。** 项目政策对系统有着广泛的影响，常常影响着项目贡献者。比如，修改支持的（编程）语言集，会影响需要调试和理解系统的人员，即使并不是所有的人都使用新语言。
 <!--
  * *Changing the system architecture.* The system architecture describes how the
    system fits together as a whole. Changing the system architecture, by
@@ -193,7 +193,7 @@ able to point you in a good direction.
 <!--
 #### Step 2: Draft {#draft}
 -->
-### 步骤二：起草 {#draft}
+#### 第二步：起草 {#draft}
 <!--
 Once you have gathered all the background and context you can through
 socialization, you are ready to start the formal part of the RFC process. The
@@ -216,13 +216,13 @@ Do not worry about assigning a number to your RFC at this stage. Instead, use
 `NNNN` as a placeholder. For example, the file name should be something like
 `NNNN_my_idea.md`. The RFC will get a number shortly before landing.
 -->
-在这个阶段不必担心您的 RFC 的序号。反之，请使用 `NNNN` 做为占位符。比如，一个文件的名字应该是 `NNNN_my_idea.md` 这种形式。RFC 文档会在合并之前不久获得一个序号。
+在这个阶段不必担心您的 RFC 的序号。反之，请使用 `NNNN` 作为占位符。比如，一个文件的名字应该是 `NNNN_my_idea.md` 这种形式。RFC 文档会在合并之前不久获得一个序号。
 <!--
 > *Suggestion.* Consider marking the CL containing your RFC as a
 > "work-in-progress" until you are ready for feedback.
 -->
 
-> **建议。** 您可以在准备好接收反馈之前，先把包含 RFC 的 CL 标记为“进行中”。
+> **建议：** 您可以在准备好接收反馈之前，先把包含 RFC 的 CL 标记为“进行中”。
 
 <!--
 #### Step 3: Iterate {#iterate}
@@ -311,7 +311,7 @@ prevent the project from accepting the RFC. See the ["How decisions are made"
 section](#how-decisions-are-made) below for more details about how the project
 decides whether to accept an RFC.
 -->
-利益相关者将代码审查标志设为 -1 或者 -2 并不一定会阻止项目接收该 RFC。要获取关于 RFC 接受决定流程的更多细节，请参阅下面的[“决定如何做出”章节](#how-decisions-are-made) 。
+利益相关者将代码审查标志设为 -1 或者 -2 并不一定会阻止项目接受该 RFC。要获取关于 RFC 接受决定流程的更多细节，请参阅下面的[“决定如何做出”章节](#how-decisions-are-made) 。
 <!--
 After all the stakeholders have weighed in with their Code-Review flags, send an
 email to [email protected] to prompt the Eng Council to decide whether to

contribute/governance/rfcs/0007_remove_thread_killing.md

@@ -1,89 +1,143 @@
-{% set rfcid = "RFC-0007" %}
-{% include "docs/contribute/governance/rfcs/_common/_rfc_header.md" %}
-# {{ rfc.name }}: {{ rfc.title }}
-<!-- SET the `rfcid` VAR ABOVE. DO NOT EDIT ANYTHING ELSE ABOVE THIS LINE. -->
-
-## Summary
-
-In the past, `zx_task_kill` allowed usermode to kill individual threads. However,
-killing individual threads encourages bad practices and has a high chance of leaving
-the process in a bad state. For this reason, the ability to kill individual threads
-should be removed.
-
-## Motivation and problem statement
-
-There is no reasonable use for usermode to kill individual threads. Exposing such facility
-encourages bad practices.
-
-On Fuchsia, like other systems, killing a thread is done asynchronously; for running threads there
-is no practical way to determine the exact place where it is safe to terminate a thread. For a
-blocked (waiting)  thread, the safer and often simple solution is to add logic so upon wakeup the
-thread exits by itself.
-
-Dangers killing a thread
-
-* Locks can be left acquired, including global locks like ones controlling the heap.
-* Memory can be leaked. At the very least the thread stack, but often many other pieces.
-* Runtime left in an inconsistent state. This is at least true for the C and Go runtime.
-* Killing a thread in its way to a syscall leaves the process in an unknown state. Kernel is
-  fine but the process does not have a way to know what happened and what did not happen.
-* Defeats RAII wrappers and automatic cleanup. In fact, it defeats most guarantees from the high
-  level languages Fuchsia uses.
-
-## Design
-
-The following syscall will fail with `ZX_ERR_NOT_SUPPORTED` when passed a handle to a thread:
-
-```
-zx_status_t zx_task_kill(zx_handle_t handle);
-```
-
-Processes and jobs will still be killable as normal.
-
-## Implementation
-
-Luckily, thread killing is not used very much in Fuchsia. The only use cases are in test code
-that checks that a thread hits a specific exception. This code is going to be updated so that
-the excepting thread exits itself after the exception is handled. For code where the exception
-is unrecoverable, the excepting thread's instruction pointer can be set directly to
-zx_thread_exit or the runtime's thread exit function before the thread resumes. These tests
-may still leak what the excepting thread had stored on the heap, but the runtime is in
-a better state, and the leaks will be collected when the test's process exits.
-
-## Performance
-
-N/A
-
-## Security considerations
-
-N/A
-
-## Privacy considerations
-
-N/A
-
-## Testing
-
-The zircon core-tests will be updated to ensure that the zx_task_kill syscall behaves as intended.
-Some amount of static analysis can be done to find call sites of zx_task_kill that are passed
-threads.
-
-The full Fuchsia Large Scale Change (LSC) process will be followed to ensure this change is
-properly tested.
-
-## Documentation
-
-The documentation for [zx_task_kill](/reference/syscalls/task_kill.md) will be updated to
-reflect that threads are not killable.
-
-## Drawbacks, Alternatives, and Unknowns
-
-The alternative to this proposal is the current status quo, which is to allow threads to be
-killed. Threads have been killable for the entire history of Fuchsia, but there has not been
-any acceptable use cases where programs have relied on this behavior. For this reason,
-we believe that thread killing can be safely removed.
-
-## Prior art and references
-
-* [Windows Vista tries to remove
-TerminateThread](https://devblogs.microsoft.com/oldnewthing/20150814-00/?p=91811)
+{% set rfcid = "RFC-0007" %}
+{% include "docs/contribute/governance/rfcs/_common/_rfc_header.md" %}
+# {{ rfc.name }}: {{ rfc.title }}
+<!-- SET the `rfcid` VAR ABOVE. DO NOT EDIT ANYTHING ELSE ABOVE THIS LINE. -->
+
+<!-- ## Summary -->
+## 概述
+
+<!-- 
+In the past, `zx_task_kill` allowed usermode to kill individual threads. However,
+killing individual threads encourages bad practices and has a high chance of leaving
+the process in a bad state. For this reason, the ability to kill individual threads
+should be removed.
+ -->
+过去，`zx_task_kill` 允许在用户态杀死单个线程。但是，杀死单个线程会为不良做法提供支持，并且很有可能使进程处于不良状态。出于这个原因，应该删除杀死单个线程的能力。
+
+<!-- ## Motivation and problem statement -->
+## 动机与问题陈述
+
+<!-- 
+There is no reasonable use for usermode to kill individual threads. Exposing such facility
+encourages bad practices.
+ -->
+对于用户态而言，杀死单个线程的做法没有合理用途。暴露此类能力会为不良做法提供支持。
+
+<!-- 
+On Fuchsia, like other systems, killing a thread is done asynchronously; for running threads there
+is no practical way to determine the exact place where it is safe to terminate a thread. For a
+blocked (waiting)  thread, the safer and often simple solution is to add logic so upon wakeup the
+thread exits by itself.
+ -->
+在 Fuchsia 上，和其他系统一样，杀死一个线程是异步完成的；对于正在运行的线程，没有实用的方法来确定可安全终止线程的确切位置。对于阻塞（等待）状态的线程，通常更安全且简单的解决方案是添加逻辑，以便在唤醒后线程自行退出。
+
+<!-- 
+Dangers killing a thread
+ -->
+杀死线程的危险
+
+<!-- 
+* Locks can be left acquired, including global locks like ones controlling the heap.
+* Memory can be leaked. At the very least the thread stack, but often many other pieces.
+* Runtime left in an inconsistent state. This is at least true for the C and Go runtime.
+* Killing a thread in its way to a syscall leaves the process in an unknown state. Kernel is
+  fine but the process does not have a way to know what happened and what did not happen.
+* Defeats RAII wrappers and automatic cleanup. In fact, it defeats most guarantees from the high
+  level languages Fuchsia uses.
+ -->
+* 锁可以被保持获取，包括像控制堆这样的全局锁。
+* 内存可能会泄漏。至少线程堆栈可能泄漏，但通常还有许多其他部分的内存会泄漏。
+* 运行时处于不一致的状态。至少对于 C 和 Go 运行时来说是这样。
+* 以系统调用的方式杀死一个线程会使进程处于未知状态。这对内核没有影响，但该进程无法知道发生了什么以及没有发生什么。
+* 破坏 RAII 包装器和自动清理。事实上，它破坏了 Fuchsia 使用的高级语言的大多数保证机制。
+
+<!-- ## Design -->
+## 设计
+
+<!-- 
+The following syscall will fail with `ZX_ERR_NOT_SUPPORTED` when passed a handle to a thread:
+ -->
+当将句柄被传递给线程时，以下系统调用将失败并返回`ZX_ERR_NOT_SUPPORTED`：
+
+```
+zx_status_t zx_task_kill(zx_handle_t handle);
+```
+
+<!-- 
+Processes and jobs will still be killable as normal.
+ -->
+进程和作业仍然可以正常地被杀死。
+
+<!-- ## Implementation -->
+## 实现
+
+<!-- 
+Luckily, thread killing is not used very much in Fuchsia. The only use cases are in test code
+that checks that a thread hits a specific exception. This code is going to be updated so that
+the excepting thread exits itself after the exception is handled. For code where the exception
+is unrecoverable, the excepting thread's instruction pointer can be set directly to
+zx_thread_exit or the runtime's thread exit function before the thread resumes. These tests
+may still leak what the excepting thread had stored on the heap, but the runtime is in
+a better state, and the leaks will be collected when the test's process exits.
+ -->
+幸运的是，Fuchsia 中并没有太多使用到杀死线程。唯一的用例是在检查线程是否遇到特定异常的测试代码中。此代码将被更新，以便异常线程在异常被处理后自行退出。对于异常无法恢复的代码，可以在线程恢复前，将异常线程的指令指针直接设置为 zx_thread_exit 或运行时的线程退出函数。这些测试可能仍然会泄漏异常线程存储在堆上的内容，但运行时会处于一个更好的状态，并且会在测试的进程退出时收集泄漏的内容。
+
+<!-- ## Performance -->
+## 性能
+
+N/A
+
+<!-- ## Security considerations -->
+## 安全性考虑
+
+N/A
+
+<!-- ## Privacy considerations -->
+## 隐私问题
+
+N/A
+
+<!-- ## Testing -->
+## 测试
+
+<!-- 
+The zircon core-tests will be updated to ensure that the zx_task_kill syscall behaves as intended.
+Some amount of static analysis can be done to find call sites of zx_task_kill that are passed
+threads.
+ -->
+Zircon 核心测试将被更新，以确保 zx_task_kill 系统调用按预期运行。可以进行一些静态分析来找到传递线程的 zx_task_kill 的调用点。
+
+<!-- 
+The full Fuchsia Large Scale Change (LSC) process will be followed to ensure this change is
+properly tested.
+ -->
+将遵循完整的 Fuchsia 大型变更（Large Scale Change，LSC）流程，以确保这一变化被正确测试。
+
+<!-- ## Documentation -->
+## 文档
+
+<!-- 
+The documentation for [zx_task_kill](/reference/syscalls/task_kill.md) will be updated to
+reflect that threads are not killable.
+ -->
+[zx_task_kill](/reference/syscalls/task_kill.md) 的文档将被更新以反映线程不可杀死。
+
+<!-- ## Drawbacks, Alternatives, and Unknowns -->
+## 缺点、替代方案和未知因素
+
+<!-- 
+The alternative to this proposal is the current status quo, which is to allow threads to be
+killed. Threads have been killable for the entire history of Fuchsia, but there has not been
+any acceptable use cases where programs have relied on this behavior. For this reason,
+we believe that thread killing can be safely removed.
+ -->
+该提议的替代方案是当前的现状，即允许线程被杀死。在 Fuchsia 的整个历史中，线程都是可以被杀死的，但是没有任何可接受的用例表明程序依赖于这种行为。出于这个原因，我们相信可以安全地删除线程杀死功能。
+
+<!-- ## Prior art and references -->
+## 现有技术和参考文献
+
+<!-- 
+* [Windows Vista tries to remove
+TerminateThread](https://devblogs.microsoft.com/oldnewthing/20150814-00/?p=91811)
+ -->
+* [Windows Vista 尝试移除 TerminateThread 方法](https://devblogs.microsoft.com/oldnewthing/20150814-00/?p=91811)

general-translation-guide.md

@@ -69,8 +69,12 @@
 
 1. 英文和中文非标点、数字和中文非标点间请用 1 个空格分割；英文或数字与中文标点间请不要空格。可以考虑使用[该软件](https://pypi.org/project/zhlint/)或类似程序进行自动化排版。
 
+1. **请不要参照英文写法在译文段落内添加单个换行**。单个换行会使得渲染后的文档内出现多余的空格。
+
 1. 为提高校对时文本的可读性，请尽量分段翻译，避免一次性注释过多段落并进行大段翻译。
 
+
+
 ### 翻译规范
 
 1. 请至少在同一目录下保持措辞一致。
@@ -120,7 +124,7 @@
      1. 原文是内联代码格式的、具有可读性的非代码内容的。
      1. 原文描述的是英文语境内容，强调了该处英文形式，且具有准确中文翻译的。
 
-     则请使用下面的方式标注：
+     对于**所在位置不是标题中的**，请使用下面的方式标注：
 
      - 如果原文不涉及全称和简称问题，则请在译文对应位置后使用全角括号标注英文原文。另外，如果原文在代码区内，则请在代码区外标注。
      - 如果原文同时具有全称和简称，或原文是未给出全称的专业术语简称，则请在译文对应位置后使用全角括号依次标注全称和简称，并在中间使用全角逗号分隔。另外，如果原文在代码区内，则请在代码区外标注。
@@ -149,6 +153,11 @@
 
       具体地，第一例中只包含全称，因此正常使用全角括号标注；第二例中包含了英文简称，故在全角括号中依次标注全称和简称，并使用全角逗号分隔；第三例在 [Google 公司的帮助文档](https://developer.android.com/guide/platform#:~:text=%E9%A2%84%E5%85%88%20(AOT)%20%E5%92%8C-,%E5%8D%B3%E6%97%B6%20(JIT)%20%E7%BC%96%E8%AF%91,-%E4%BC%98%E5%8C%96%E7%9A%84)中已有译例，因此按照固定方式翻译和标注。
 
+      对于**所在位置是标题中的**，请使用下面的方法标注：
+
+      - 如果在正文中出现了该概念，则应当在正文进行标注，而不应在标题中进行标注。
+      - 如果在正文中未出现该概念，则除非：（1）翻译具有较大歧义性，或（2）在其他文章中再次出现（即证明本身是重要概念），这些情况可以在标题中标注原文，否则不应在标题中标注原文（即不进行标注）。
+
     - **原文作正文，标注译文。** 如果满足下列条件之一：
 
       1. 原文是未适配中文的输出内容的。

get-started/_common/components/_debugging_intro.md

@@ -1,4 +1,7 @@
+<!-- 
 Developing software means dealing with program crashes and uncovering the
 source of bugs. Fuchsia has a suite of tools to help identify and diagnose
 issues in your components from analyzing crash logs to full step-through
 debugging in core code.
+ -->
+开发软件意味着要处理程序崩溃和发现错误的根源。Fuchsia 有一套工具来帮助识别和诊断组件中的问题，从分析崩溃日志到在核心代码中进行完整的逐步调试。

get-started/_common/components/_declaring_intro.md

@@ -1,15 +1,24 @@
+<!-- 
 Every component has a declaration that describes the component's attributes and
 capabilities. For components that are distributed in packages, the declaration
 is expressed using a **component manifest file** and loaded with the help of a
 **component resolver**.
+ -->
+每个组件（component）都有一个声明，描述组件属性和功能。对于在软件包中分发的组件，其声明使用**组件清单（component manifest）文件**表示，并在**组件解析器**的帮助下加载。
 
+<!-- 
 ![Diagram showing how components are declared using a "component manifest." The
 manifest is compiled by the developer tools and resolved onto the device at
 runtime.](/get-started/images/components/component-manifest.png){: width="836"}
+ -->
+![该图显示了如何使用“组件清单”来声明组件。该清单由开发者工具编译，并在运行时解析到设备上。](/get-started/images/components/component-manifest.png){: width="836"}
 
+<!-- 
 You declare components using component manifest language (CML) files. At build
 time, the Component Manifest Compiler (`cmc`) tool validates and compiles the
 manifest source into a binary format (`.cm`) and stores it in the component's
 package. At runtime, component resolvers load the binary manifest into a
 [ComponentDecl](https://fuchsia.dev/reference/fidl/fuchsia.component.decl#Component)
 FIDL structure for [Component Manager](/glossary/README.md#Component-Manager).
+ -->
+请您使用组件清单语言（CML）文件声明组件。在构建时，组件清单编译器（`cmc`）工具会验证清单源并将其编译为二进制格式（`.cm`），并将其存储在组件的软件包中。在运行时，组件解析器将二进制清单文件加载到[组件管理器](/glossary/README.md#Component-Manager)的 [ComponentDecl](https://fuchsia.dev/reference/fidl/fuchsia.component.decl#Component) FIDL 结构中。