klion26 commented on a change in pull request #11808:
URL: https://github.com/apache/flink/pull/11808#discussion_r442849221
##########
File path: docs/dev/stream/operators/process_function.zh.md
##########
@@ -26,66 +26,59 @@ under the License.
* This will be replaced by the TOC
{:toc}
-## The ProcessFunction
+## ProcessFunction 简介
-The `ProcessFunction` is a low-level stream processing operation, giving
access to the basic building blocks of
-all (acyclic) streaming applications:
+`ProcessFunction` 是一种低级别的流处理操作，基于它用户可以访问（无环）流应用程序的所有基本构建块：
- - events (stream elements)
- - state (fault-tolerant, consistent, only on keyed stream)
- - timers (event time and processing time, only on keyed stream)
+ - 事件（流元素）
+ - 状态（容错，一致性，仅在 keyed stream 上）
+ - 计时器（事件时间和处理时间，仅在 keyed stream 上）
-The `ProcessFunction` can be thought of as a `FlatMapFunction` with access to
keyed state and timers. It handles events
-by being invoked for each event received in the input stream(s).
+可以将 `ProcessFunction` 视为一种可以访问 keyed state 和计时器的 `FlatMapFunction`。Flink
为收到的输入流中的每个事件都调用该函数来进行处理。
-For fault-tolerant state, the `ProcessFunction` gives access to Flink's [keyed
state]({{ site.baseurl }}/dev/stream/state/state.html), accessible via the
-`RuntimeContext`, similar to the way other stateful functions can access keyed
state.
+对于容错，与其它有状态的函数类似，`ProcessFunction` 可以通过 `RuntimeContext` 访问 Flink 的 [keyed
state]({{ site.baseurl }}/zh/dev/stream/state/state.html)。
Review comment:
现在链接建议使用 `{%link stream/state/state.zh.md %}`
的格式了，具体的可以参考这个[邮件](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Reminder-Prefer-link-tag-in-documentation-td42362.html)
其他地方也一起改一下吧~
##########
File path: docs/dev/stream/operators/process_function.zh.md
##########
@@ -26,66 +26,59 @@ under the License.
* This will be replaced by the TOC
{:toc}
-## The ProcessFunction
+## ProcessFunction 简介
-The `ProcessFunction` is a low-level stream processing operation, giving
access to the basic building blocks of
-all (acyclic) streaming applications:
+`ProcessFunction` 是一种低级别的流处理操作，基于它用户可以访问（无环）流应用程序的所有基本构建块：
- - events (stream elements)
- - state (fault-tolerant, consistent, only on keyed stream)
- - timers (event time and processing time, only on keyed stream)
+ - 事件（流元素）
+ - 状态（容错，一致性，仅在 keyed stream 上）
+ - 计时器（事件时间和处理时间，仅在 keyed stream 上）
-The `ProcessFunction` can be thought of as a `FlatMapFunction` with access to
keyed state and timers. It handles events
-by being invoked for each event received in the input stream(s).
+可以将 `ProcessFunction` 视为一种可以访问 keyed state 和计时器的 `FlatMapFunction`。Flink
为收到的输入流中的每个事件都调用该函数来进行处理。
-For fault-tolerant state, the `ProcessFunction` gives access to Flink's [keyed
state]({{ site.baseurl }}/dev/stream/state/state.html), accessible via the
-`RuntimeContext`, similar to the way other stateful functions can access keyed
state.
+对于容错，与其它有状态的函数类似，`ProcessFunction` 可以通过 `RuntimeContext` 访问 Flink 的 [keyed
state]({{ site.baseurl }}/zh/dev/stream/state/state.html)。
-The timers allow applications to react to changes in processing time and in
[event time]({{ site.baseurl }}/dev/event_time.html).
-Every call to the function `processElement(...)` gets a `Context` object which
gives access to the element's
-event time timestamp, and to the *TimerService*. The `TimerService` can be
used to register callbacks for future
-event-/processing-time instants. With event-time timers, the `onTimer(...)`
method is called when the current watermark is advanced up to or beyond the
timestamp of the timer, while with processing-time timers, `onTimer(...)` is
called when wall clock time reaches the specified time. During that call, all
states are again scoped to the key with which the timer was created, allowing
-timers to manipulate keyed state.
+计时器允许应用程序对处理时间和[事件时间]({{ site.baseurl }}/zh/dev/event_time.html)中的更改做出反应。
+每次调用 `processElement(...)` 时参数中都会提供一个 `Context` 对象，该对象可以访问元素的事件时间戳和
*TimerService*。
+`TimerService` 可用于为将来特定的事件时间/处理时间注册回调。
+特定事件时间的 `onTimer(...)` 回调函数会在当前对齐的 watermark 超过所注册的时间戳时调用。
+特定处理时间的 `onTimer(...)` 回调函数则会在物理时间注册时间时调用。
Review comment:
`物理时间注册时间时` 这个读起来感觉有点拗口，能优化下吗
##########
File path: docs/dev/stream/operators/process_function.zh.md
##########
@@ -284,30 +274,30 @@ override def onTimer(timestamp: Long, ctx:
OnTimerContext, out: Collector[OUT]):
## Timers
-Both types of timers (processing-time and event-time) are internally
maintained by the `TimerService` and enqueued for execution.
+两种计时器（处理时间计时器和事件时间计时器）都在 `TimerService` 内部维护，并排队等待执行。
-The `TimerService` deduplicates timers per key and timestamp, i.e., there is
at most one timer per key and timestamp. If multiple timers are registered for
the same timestamp, the `onTimer()` method will be called just once.
+对于相同的键和时间戳，`TimerService` 会删除重复的计时器，即每个键和时间戳最多有一个计时器。如果为同一时间戳注册了多个计时器，则只调用一次
`onTimer()` 方法。
-<span class="label label-info">Note</span> Flink synchronizes invocations of
`onTimer()` and `processElement()`. Hence, users do not have to worry about
concurrent modification of state.
+<span class="label label-info">注意</span> Flink 会同步 `onTimer()` 和
`processElement()` 的调用，因此用户不必担心状态的并发修改。
### Fault Tolerance
-Timers are fault tolerant and checkpointed along with the state of the
application.
-In case of a failure recovery or when starting an application from a
savepoint, the timers are restored.
+计时器支持容错，它会和应用程序的状态一起进行 checkpoint。当进行故障恢复或从保存点启动应用程序时，计时器也会被恢复。
-<span class="label label-info">Note</span> Checkpointed processing-time timers
that were supposed to fire before their restoration, will fire immediately.
-This might happen when an application recovers from a failure or when it is
started from a savepoint.
+<span class="label label-info">注意</span>
在恢复之前就应该触发的处理时间计时器会立即触发。当应用程序从故障中恢复或从保存点启动时，可能会发生这种情况。
-<span class="label label-info">Note</span> Timers are always asynchronously
checkpointed, except for the combination of RocksDB backend / with incremental
snapshots / with heap-based timers (will be resolved with `FLINK-10026`).
-Notice that large numbers of timers can increase the checkpointing time
because timers are part of the checkpointed state. See the "Timer Coalescing"
section for advice on how to reduce the number of timers.
+<span class="label label-info">注意</span> 除了使用基于 RocksDB backend 的增量 snapshots
并使用基于 Heap 的计时器的情况外，Flink 总是会异步执行计算器的快照操作（前者将会在 `FLINK-10026` 解决）。
+
+<span class="label label-info">注意</span> 大量计时器会增加 checkpoint 的时间，因为计时器是需要
checkpoint 的状态的一部分。有关如何减少计时器数量，请参阅“计时器合并”部分。
### Timer Coalescing
-Since Flink maintains only one timer per key and timestamp, you can reduce the
number of timers by reducing the timer resolution to coalesce them.
+由于 Flink 中每个键和时间戳只保存一个计时器，因此可以通过降低计时器的精度来合并它们，从而减少计时器的数量。
+
-For a timer resolution of 1 second (event or processing time), you
-can round down the target time to full seconds. Timers will fire at most 1
second earlier but not later than requested with millisecond accuracy.
-As a result, there are at most one timer per key and second.
+对于精度为 1 秒（事件或处理时间）的计时器，可以将目标时间
+向下舍入为整秒。计时器最多会提前 1 秒，但不迟于要求的毫秒精度。
Review comment:
建议这一行和上一行合并，不然渲染出来的效果，“目标时间”和“向下舍入”中间有空格。
##########
File path: docs/dev/stream/operators/process_function.zh.md
##########
@@ -284,30 +274,30 @@ override def onTimer(timestamp: Long, ctx:
OnTimerContext, out: Collector[OUT]):
## Timers
-Both types of timers (processing-time and event-time) are internally
maintained by the `TimerService` and enqueued for execution.
+两种计时器（处理时间计时器和事件时间计时器）都在 `TimerService` 内部维护，并排队等待执行。
-The `TimerService` deduplicates timers per key and timestamp, i.e., there is
at most one timer per key and timestamp. If multiple timers are registered for
the same timestamp, the `onTimer()` method will be called just once.
+对于相同的键和时间戳，`TimerService` 会删除重复的计时器，即每个键和时间戳最多有一个计时器。如果为同一时间戳注册了多个计时器，则只调用一次
`onTimer()` 方法。
-<span class="label label-info">Note</span> Flink synchronizes invocations of
`onTimer()` and `processElement()`. Hence, users do not have to worry about
concurrent modification of state.
+<span class="label label-info">注意</span> Flink 会同步 `onTimer()` 和
`processElement()` 的调用，因此用户不必担心状态的并发修改。
### Fault Tolerance
-Timers are fault tolerant and checkpointed along with the state of the
application.
-In case of a failure recovery or when starting an application from a
savepoint, the timers are restored.
+计时器支持容错，它会和应用程序的状态一起进行 checkpoint。当进行故障恢复或从保存点启动应用程序时，计时器也会被恢复。
-<span class="label label-info">Note</span> Checkpointed processing-time timers
that were supposed to fire before their restoration, will fire immediately.
-This might happen when an application recovers from a failure or when it is
started from a savepoint.
+<span class="label label-info">注意</span>
在恢复之前就应该触发的处理时间计时器会立即触发。当应用程序从故障中恢复或从保存点启动时，可能会发生这种情况。
-<span class="label label-info">Note</span> Timers are always asynchronously
checkpointed, except for the combination of RocksDB backend / with incremental
snapshots / with heap-based timers (will be resolved with `FLINK-10026`).
-Notice that large numbers of timers can increase the checkpointing time
because timers are part of the checkpointed state. See the "Timer Coalescing"
section for advice on how to reduce the number of timers.
+<span class="label label-info">注意</span> 除了使用基于 RocksDB backend 的增量 snapshots
并使用基于 Heap 的计时器的情况外，Flink 总是会异步执行计算器的快照操作（前者将会在 `FLINK-10026` 解决）。
+
+<span class="label label-info">注意</span> 大量计时器会增加 checkpoint 的时间，因为计时器是需要
checkpoint 的状态的一部分。有关如何减少计时器数量，请参阅“计时器合并”部分。
Review comment:
这个地方使用了 `计时器合并` 但是下面的标题没有进行翻译，不确定用户看到这个能想到需要跳转到那。
PS：如果翻译下面的标题的话，注意需要添加一个 <b> 标签，具体可以参考
[wiki](https://cwiki.apache.org/confluence/display/FLINK/Flink+Translation+Specifications?src=contextnavpagetreemode)
```
为了使链接仍然有效，我们需要在翻译后的标题上增加一个 <a name="original_titile_anchor"></a> 标签。
如原标题：
## Convert a Table into a DataStream
翻译后需要在标题前增加一个 <a> 标签，注意 <a> 和标题之间有一个空行。
<a name="table-to-stream-conversion"></a>
## 将表转换成 DataStream
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
