chore(i18n): crowdin sync (#5207)

Co-authored-by: Claudio Wunder <cwunder@gnome.org>
Co-authored-by: Claudio Wunder <cwunder@hubspot.com>

Author: nodejs-github-bot

crowdin.yml

@@ -1,6 +1,6 @@
-commit_message: "chore(i18n): added new translations from crowdin"
-pull_request_title: "chore(i18n): crowdin sync"
-pull_request_labels: 
+commit_message: 'chore(i18n): added new translations from crowdin'
+pull_request_title: 'chore(i18n): crowdin sync'
+pull_request_labels:
   - i18n
   - crowdin
 files:

pages/id/docs/index.mdx

@@ -0,0 +1,38 @@
+---
+title: Dokumentasi
+layout: docs.hbs
+labels:
+  lts: LTS
+---
+
+# Mengenai Dokumentasi
+
+Ada beberapa jenis dokumentasi yang tersedia di situs ini:
+
+- Dokumentasi Referensi API
+- Fitur ES6
+- Panduan
+
+## Dokumentasi Referensi API
+
+[Dokumentasi referensi API](https://nodejs.org/api/) memberikan informasi mendetail tentang fungsi atau objek di Node.js. Dokumentasi ini menunjukkan argumen apa yang diterima suatu metode, nilai kembalian dari metode itu, dan kesalahan apa yang mungkin terkait dengan metode itu. Ini juga menunjukkan metode mana yang tersedia untuk berbagai versi Node.js.
+
+Dokumentasi ini menjelaskan modul bawaan yang disediakan oleh Node.js. Itu tidak mendokumentasikan modul yang disediakan oleh komunitas.
+
+<div className="highlight-box">
+
+### Mencari dokumen API dari rilis sebelumnya?
+
+<NodeApiVersionLinks />
+
+[Semua versi](https://nodejs.org/docs/)
+
+</div>
+
+## Fitur ES6
+
+[Bagian ES6](/id/docs/es6/) menjelaskan tiga grup fitur ES6, dan detail fitur mana yang diaktifkan secara default di Node.js, bersama tautan penjelasan. Ini juga menunjukkan cara menemukan versi V8 mana yang disertakan dengan rilis Node.js tertentu.
+
+## Panduan
+
+[Bagian Panduan](/id/docs/guides/) memiliki artikel panjang dan mendalam tentang fitur dan kemampuan teknis Node.js.

pages/id/download/index.md

@@ -15,7 +15,7 @@ downloads:
   buildInstructions: Membangun Node.js dari sumber pada platform yang didukung
   WindowsInstaller: Instalasi Windows
   WindowsBinary: Windows Binary
-  MacOSInstaller: macOS Installer
+  MacOSInstaller: Instalasi macOS
   MacOSBinary: macOS Binary
   LinuxBinaries: Linux Binaries
   SourceCode: Kode Sumber

pages/zh-cn/about/index.md

@@ -1,7 +1,7 @@
 ---
 layout: about.hbs
-title: 关于
-trademark: Trademark
+title: 关于 Node.js
+trademark: 商标
 ---
 
 # 关于 Node.js®
@@ -30,6 +30,7 @@ server.listen(port, hostname, () => {
 如果你对上面的描述有一些不理解地方，这里有一篇专门关于[阻塞对比非阻塞][]的文章供你参考。
 
 ---
+
 Node.js 在设计上类似于 Ruby 的 [Event Machine][] 或 Python 的 [Twisted][] 之类的系统。但 Node.js 更深入地考虑了事件模型，它将[事件循环][]作为一个运行时结构而不是作为一个库来呈现。在其他系统中，总是有一个阻塞调用来启动事件循环。通常情况下，要执行的行为是通过脚本开始时的回调来定义的，然后通过 `EventMachine::run()` 这样的阻塞调用来启动服务器。而在 Node.js 中，没有这种启动事件循环的调用。Node.js 在执行输入脚本后直接进入事件循环，当没有更多的回调要执行时，Node.js 就会退出事件循环。这种行为就像浏览器的 JavaScript 一样 —— 事件循环对用户是隐藏的。
 
 HTTP 是 Node.js 中的一等公民，设计时考虑到了流式和低延迟，这使得 Node.js 非常适合作为网络库或框架的基础。

pages/zh-cn/docs/guides/backpressuring-in-streams.md

@@ -21,7 +21,7 @@ layout: docs.hbs
 
 如果你想诊断发布的生产环境，请阅读[在生产环境中的 0x][]。
 
-### <!--create-a-flame-graph-with-system-perf-tools-->用系统工具 `pref` 创建火焰图
+### 用系统工具 pref 创建火焰图
 
 本教程的目的在于给你展示如何创建火焰图的具体步骤，这样让你可以对每一步都有掌控。
 
@@ -34,11 +34,11 @@ layout: docs.hbs
 3. 启用 pref 并运行 node（具体参考 [perf 输出的问题](#perf-output-issues)以此了解针对不同 Node.js 版本的建议）
 
     ```bash
-    perf record -e cycles:u -g -- node --perf-basic-prof app.js
+    perf recording -e cycles:u -g -- node --perf-basic-prof app.js
     ```
 
 4. 忽略一些警告，除非它告诉你因为缺少必要的安装包而无法运行 pref，你可能会得到一些警告，告诉你不能访问内核模块的样本等。
-5. 运行命令 `perf script > perfs.out` 生成稍后你看到的可视化的数据文件。对于一个易读的火焰图而言，[应用清理](#filtering-out-node-internal-functions)是有作用的。
+5. 运行命令 `perf script > perfs.out` 生成稍后你看到的可视化的数据文件。对于一个易读的火焰图而言，[应用清理](#filtering-out-node-js-internal-functions)是有作用的。
 6. 如果没有安装 stackvis，请运行 `npm i -g stackvis`
 7. 最后运行 `stackvis perf < perfs.out > flamegraph.htm`
 
@@ -66,9 +66,9 @@ perf record -F99 -p `pgrep -n node` -g -- sleep 3
 
 ```bash
 sed -i -r \
-  -e "/( __libc_start| LazyCompile | v8::internal::| Builtin:| Stub:| LoadIC:|\[unknown\]| LoadPolymorphicIC:)/d" \
-  -e 's/ LazyCompile:[*~]?/ /' \
-  perfs.out
+  -e "/( __libc_start| LazyCompile | v8::internal::| Builtin:| Stub:| LoadIC:|\[unknown\]| LoadPolymorphicIC:)/d"
+  -e 's/ LazyCompile:[*~]? /' \
+  amouns.out
 ```
 
 如果你现在读火焰图，就会觉得它看上去很怪 —— 花费了多数时间的主要函数就像丢了什么一样，你可以尝试不使用过滤参数，那么你也许得到一个罕见的情况下 Node.js 自身的问题。
@@ -83,7 +83,7 @@ sed -i -r \
 
 当然，如果没有这些参数的话，你照样可以得到火焰图。不过大部分的条状都将被标记为 `v8::Function::Call`。
 
-## <!--perf-output-issues-->`perf` 输出的一些问题
+## `perf` 输出的一些问题
 
 ### Node.js 8.x V8 管道上的变化
 
@@ -111,7 +111,7 @@ Node.js 10.x 使用 `--interpreted-frames-native-stack` 标志解决了“Turbof
 如果你看到诸如以下的标签：
 
 ```
-node`_ZN2v88internal11interpreter17BytecodeGenerator15VisitStatementsEPNS0_8ZoneListIPNS0_9StatementEEE
+node`_ZN2v88internal11interpretter17BytecodeGenerator15VisitStatementsEPNS0_8ZoneListIPNS0_9StatementEE
 ```
 
 这意味着你正在运行的 Linux 的 perf 没有用 demangle 支持方法编译，请以 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396654 作为示例参考。

pages/zh-cn/docs/guides/diagnostics-flamegraph.md

@@ -1,17 +1,18 @@
 ---
-title: Diagnostics Guide
+title: 诊断指南
 layout: docs.hbs
 ---
 
 # 诊断指南
 
-这些指南在[诊断工作小组](https://github.com/nodejs/diagnostics)中得以创建，
-其目的旨在诊断一个程序中的相关问题时能给予相应的指导。
-本文档基于用户亲历组织而成。这些历程是一系列互相关联、一步步的措施。
-用户应当遵从他们，以便于根据用户上报的事件锁定问题。
+这些指南在[诊断工作小组][]中得以创建，其目的旨在诊断一个程序中的相关问题时能给予相应的指导。
 
-以下即是相关的系列诊断指南：
+本文档基于用户亲历组织而成。这些历程是一系列互相关联、一步步的措施。用户应当遵从他们，以便于根据用户上报的事件锁定问题。
 
-* [内存诊断相关](/zh-cn/docs/guides/diagnostics/memory)
-* [在线调试](/zh-cn/docs/guides/diagnostics/live-debugging)
-* [低效率运行](/zh-cn/docs/guides/diagnostics/poor-performance)
+这是可用的诊断指南：
+
+* [内存诊断相关](/zh-cn/docs/guides/diagnotics/memory)
+* [在线调试](/zh-cn/docs/guides/diagnostics/live-debugging/using-inspector)
+* [低效率运行](/zh-cn/docs/guides/diagnics/poor-performance)
+
+[诊断工作小组]: https://github.com/nodejs/diagnostics

pages/zh-cn/docs/guides/diagnostics/index.md

@@ -361,8 +361,7 @@ class DataStream {
 
 虽然这可能不会影响每秒只有几百甚至一千个请求的服务器，但开销的数量与异步请求的数量成正比。因此，如果单个连接需要连接到其它几个服务，所有这些都将对最终交付给客户机的等待时间产生影响。
 
-使用 `AsyncWrap` 并跟踪次数
-`init`/`pre`/`post`/`destroy` 在以上基准中所提及，我们发现所有事件的总和超过每秒 170000 次。这意味着即使为每种类型的设置增加 1 微秒的开销，任何类型的安装或拆除都会导致 17% 的性能损失。当然，这是针对基准的优化方案，但我相信这证明了一种机制，如域尽可能简单方便地运行的必要性。
+使用 `AsyncWrap` 并跟踪次数 `init`/`pre`/`post`/`destroy` 在以上基准中所提及，我们发现所有事件的总和超过每秒 170000 次。这意味着即使为每种类型的设置增加 1 微秒的开销，任何类型的安装或拆除都会导致 17% 的性能损失。当然，这是针对基准的优化方案，但我相信这证明了一种机制，如域尽可能简单方便地运行的必要性。
 
 ## 展望未来