diff --git a/2-ui/5-loading/01-onload-ondomcontentloaded/article.md b/2-ui/5-loading/01-onload-ondomcontentloaded/article.md
index 322517af39..8c8817139a 100644
--- a/2-ui/5-loading/01-onload-ondomcontentloaded/article.md
+++ b/2-ui/5-loading/01-onload-ondomcontentloaded/article.md
@@ -1,39 +1,39 @@
-# Page: DOMContentLoaded, load, beforeunload, unload
+# 页面生命周期：DOMContentLoaded，load，beforeunload，unload
 
-The lifecycle of an HTML page has three important events:
+HTML 页面的生命周期有三个重要事件：
 
-- `DOMContentLoaded` -- the browser fully loaded HTML, and the DOM tree is built, but external resources like pictures `<img>` and stylesheets may be not yet loaded.  
-- `load` -- not only HTML is loaded, but also all the external resources: images, styles etc.
-- `beforeunload/unload` -- the user is leaving the page.
+- `DOMContentLoaded` —— 浏览器完成全部 HTML 的加载，并构建 DOM 树，但像 `<img>` 和样式这样的外部资源可能还没有加载完成。
+- `load` —— 浏览器加载完所有资源，包括 HTML 文档，图像，样式等。
+- `beforeunload/unload` —— 当用户离开页面时。
 
-Each event may be useful:
+每个事件都是有用的：
 
-- `DOMContentLoaded` event -- DOM is ready, so the handler can lookup DOM nodes, initialize the interface.
-- `load` event -- external resources are loaded, so styles are applied, image sizes are known etc.
-- `beforeunload` event -- the user is leaving: we can check if the user saved the changes and ask them whether they really want to leave.
-- `unload` -- the user almost left, but we still can initiate some operations, such as sending out statistics.
+- `DOMContentLoaded` 事件 —— DOM 已经准备好，因此事件处理器可以查找 DOM 节点，并初始化接口。
+- `load` 事件 —— 外部资源加载完成后，我们就可以应用样式表，获取图像大小等。
+- `beforeunload` 事件 —— 用户即将离开：我们可以检查用户是否保存了修改，并询问他是否真的要离开。
+- `unload` 事件 —— 用户几乎已经离开了，但是我们仍然可以启动一些操作，比如发送统计数据。
 
-Let's explore the details of these events.
+我们探讨一下这些事件的细节。
 
 ## DOMContentLoaded
 
-The `DOMContentLoaded` event happens on the `document` object.
+`DOMContentLoaded` 事件发生在 `document` 对象上。
 
-We must use `addEventListener` to catch it:
+我们必须使用 `addEventListener` 来监听它：
 
 ```js
 document.addEventListener("DOMContentLoaded", ready);
-// not "document.onDOMContentLoaded = ..."
+// 不同于“document.onDOMContentLoaded = ...”
 ```
 
-For instance:
+例如：
 
 ```html run height=200 refresh
 <script>
   function ready() {
     alert('DOM is ready');
 
-    // image is not yet loaded (unless was cached), so the size is 0x0
+    // 图像尚未加载（除非已经有了缓存）因此其大小是 0x0
     alert(`Image size: ${img.offsetWidth}x${img.offsetHeight}`);
   }
 
@@ -45,17 +45,17 @@ For instance:
 <img id="img" src="https://en.js.cx/clipart/train.gif?speed=1&cache=0">
 ```
 
-In the example the `DOMContentLoaded` handler runs when the document is loaded, so it can see all the elements, including `<img>` below.
+在示例中，`DOMContentLoaded` 处理器在文档加载完成后触发，所以它可以访问到所有的元素，包括它下面的 `<img>` 元素。
 
-But it doesn't wait for the image to load. So `alert` shows zero sizes.
+但是它不会等待图像加载完成，因此 `alert` 显示其大小为零。
 
-At the first sight `DOMContentLoaded` event is very simple. The DOM tree is ready -- here's the event. There are few peculiarities though.
+初识 `DOMContentLoaded` 事件时，觉得它比较简单。DOM 树准备就绪 —— 这是它的触发条件。它并没有什么特别之处。
 
-### DOMContentLoaded and scripts
+### DOMContentLoaded 和脚本
 
-When the browser processes an HTML-document and comes across a `<script>` tag, it needs to execute before continuing building the DOM. That's a precaution, as scripts may want to modify DOM, and even `document.write` into it, so `DOMContentLoaded` has to wait.
+当浏览器开始加载 HTML 文档并在文档中遇到 `<script>` 标签时，就会在继续构建 DOM 之前运行它。这是一个防范措施，因为脚本可能想要修改 DOM，甚至对其执行 `document.write` 操作，所以 `DOMContentLoaded` 必须等待它执行结束。
 
-So DOMContentLoaded definitely happens after such scripts:
+因此，在下面的这些脚本执行结束之后肯定会发生 DOMContentLoaded：
 
 ```html run
 <script>
@@ -71,54 +71,54 @@ So DOMContentLoaded definitely happens after such scripts:
 </script>
 ```
 
-In the example above, we first see "Library loaded...", and then "DOM ready!" (all scripts are executed).
+在上面的例子中，我们首先会看到“Library loaded...”，然后才会看到“DOM ready!”（所有脚本都已经执行结束）。
 
-```warn header="Scripts with `async`, `defer` or `type=\"module\"` don't block DOMContentLoaded"
+```warn header="具有 `async`, `defer` or `type=\"module\"` 属性的脚本不会阻塞 DOMContentLoaded"
+我们[稍后会提到的](info:script-async-defer)脚本属性 `async` 和 `defer`，它们不会阻塞 DOMContentLoaded。[JavaScript 模块](info:modules)的行为和 `defer` 相似，同样也不会阻塞 DOMContentLoaded。
 
-Script attributes `async` and `defer`, that we'll cover [a bit later](info:script-async-defer), don't block DOMContentLoaded. [JavaScript modules](info:modules) behave like `defer`,  they don't block it too.
-
-So here we're talking about "regular" scripts, like `<script>...</script>`, or `<script src="..."></script>`.
+所以在这里，我们研究的是“普通”脚本，比如 `<script>...</script>` 或者 `<script src="..."></script>`。
 ```
 
-### DOMContentLoaded and styles
 
-External style sheets don't affect DOM, so `DOMContentLoaded` does not wait for them.
+### DOMContentLoaded 和样式
+
+外部样式不会影响 DOM，因此 `DOMContentLoaded` 无需等待它们。
 
-But there's a pitfall. If we have a script after the style, then that script must wait until the stylesheet loads:
+但有一个陷阱。如果在样式之后有一个脚本，那么该脚本必须等待样式被加载：
 
 ```html
 <link type="text/css" rel="stylesheet" href="style.css">
 <script>
-  // the script doesn't not execute until the stylesheet is loaded
+  // 在样式表加载之前，脚本都不会执行
   alert(getComputedStyle(document.body).marginTop);
 </script>
 ```
 
-The reason is that the script may want to get coordinates and other style-dependent properties of elements, like in the example above. Naturally, it has to wait for styles to load.
+原因是脚本可能希望获取如上述示例所描述的元素坐标和其他与样式相关的属性。因此，它必须等待样式被加载。
 
-As `DOMContentLoaded` waits for scripts, it now waits for styles before them as well.
+当 `DOMContentLoaded` 等待脚本时，它也在等待脚本之前的样式。
 
-### Built-in browser autofill
+### 浏览器内置的自动填充
 
-Firefox, Chrome and Opera autofill forms on `DOMContentLoaded`.
+Firefox、Chrome 和 Opera 都会在 `DOMContentLoaded` 中自动填写表单。
 
-For instance, if the page has a form with login and password, and the browser remembered the values, then on `DOMContentLoaded` it may try to autofill them (if approved by the user).
+比如，如果页面有一个带有登录和密码的表单，并且浏览器记住了这些值，那么在 `DOMContentLoaded` 触发时，它就可以尝试自动填写它们（如果用户允许的话）。
 
-So if `DOMContentLoaded` is postponed by long-loading scripts, then autofill also awaits. You probably saw that on some sites (if you use browser autofill) -- the login/password fields don't get autofilled immediately, but there's a delay till the page fully loads. That's actually the delay until the `DOMContentLoaded` event.
+因此，如果 `DOMContentLoaded` 被需要加载很长时间的脚本延迟触发，那么自动填充也在等待。你可能在某些站点上看到过（如果你使用浏览器自动填写） —— 登录/密码字段并不会立即自动填充，而是在页面被完全加载前会延迟填充。这实际上是 `DOMContentLoaded` 事件之前的延迟。
 
 
 ## window.onload [#window-onload]
 
-The `load` event on the `window` object triggers when the whole page is loaded including styles, images and other resources.
+当包括样式、图像和其他资源的页面被全部加载时，`window` 对象上的 `load` 事件就会被触发。
 
-The example below correctly shows image sizes, because `window.onload` waits for all images:
+以下示例正确地显示了图像大小，因为 `window.onload` 会等待所有的图像加载完毕：
 
 ```html run height=200 refresh
 <script>
   window.onload = function() {
     alert('Page loaded');
 
-    // image is loaded at this time
+    // 此时图像已经加载完成
     alert(`Image size: ${img.offsetWidth}x${img.offsetHeight}`);
   };
 </script>
@@ -128,45 +128,44 @@ The example below correctly shows image sizes, because `window.onload` waits for
 
 ## window.onunload
 
-When a visitor leaves the page, the `unload` event triggers on `window`. We can do something there that doesn't involve a delay, like closing related popup windows.
+当访问者离开页面时，`window` 对象上的 `unload` 事件就会被触发。我们可以在那里做一些不涉及延迟的事件，比如关闭相关的弹出窗口。
 
-The notable exception is sending analytics.
+有一个值得注意的特殊情况那就是发送分析数据。
 
-Let's say we gather data about how the page is used: mouse clicks, scrolls, viewed page areas, and so on.
+假设我们要收集页面使用情况的数据：鼠标点击、滚动、被查看的页面区域等等。
 
-Naturally, `unload` event is when the user leaves us, and we'd like to save the data on our server.
+自然地，当用户要离开的时候，我们会使用 `unload` 事件去发送我们想要保存在服务器上的数据。
 
-There exists a special `navigator.sendBeacon(url, data)` method for such needs, described in the specification <https://w3c.github.io/beacon/>.
+这里也有一个特殊的 `navigator.sendBeacon(url, data)` 方法来实现这种需求，请参见 w3c 规范 <https://w3c.github.io/beacon/>。
 
-It sends the data in background. The transition to another page is not delayed: the browser leaves the page, but still performs `sendBeacon`.
+它在后台发送数据，转换到另外一个页面时不会被延迟：浏览器离开页面，但仍然在执行 `sendBeacon`。
 
-Here's how to use it:
-```js
-let analyticsData = { /* object with gathered data */ };
+下面是它的使用示例：
 
+```js
+let analyticsData = { /* 收集了数据的对象 */ };
 window.addEventListener("unload", function() {
   navigator.sendBeacon("/analytics", JSON.stringify(analyticsData));
 };
 ```
 
-- The request is sent as POST.
-- We can send not only a string, but also forms and other formats, as described in the chapter <info:fetch-basics>, but usually it's a stringified object.
-- The data is limited by 64kb.
-
-When the `sendBeacon` request is finished, the browser probably has already left the document, so there's no way to get server response (which is usually empty for analytics).
+- 请求以 POST 方式发送。
+- 我们不仅能发送字符串，还能发送表单以及其他格式的数据，在 <info:fetch-basics> 章节我们已有说明，但是通常情况下它是一个字符串化的对象。
+- 数据大小限制在 64kb。
 
-There's also a `keepalive` flag for doing such "after-page-left" requests in  [fetch](info:fetch-basics) method for generic network requests. You can find more information in the chapter <info:fetch-api>.
+当 `sendBeacon` 请求完成的时候，浏览器可能已经离开了文档，所以就没办法获取服务器的响应数据（对于统计数据来说通常是空的）。
 
+还有一个 `keep-alive` 的标志，用于在 [fetch](info:fetch-basics) 方法中为通用的网络请求执行此类“离开页面后（after-page-left）”的请求。你可以在 <info:fetch-api> 章节中了解到更多相关信息。
 
-If we want to cancel the transition to another page, we can't do it here. But we can use  another event -- `onbeforeunload`.
+如果我们要取消跳转到另一页面的操作，在这里做不到。但是我们可以用另外一个事件 —— `onbeforeunload`。
 
 ## window.onbeforeunload [#window.onbeforeunload]
 
-If a visitor initiated navigation away from the page or tries to close the window, the `beforeunload` handler asks for additional confirmation.
+如果访问中触发了离开页面的导航或试图关闭窗口，`beforeunload` 处理器将要求提供更多的确认信息。
 
-If we cancel the event, the browser may ask the visitor if they are sure.
+如果我们取消该事件，浏览器将会询问用户是否确定。
 
-You can try it by running this code and then reloading the page:
+你可以通过运行这段代码，然后重新加载页面来进行尝试：
 
 ```js run
 window.onbeforeunload = function() {
@@ -174,9 +173,9 @@ window.onbeforeunload = function() {
 };
 ```
 
-For historical reasons, returning a non-empty string also counts as canceling the event. Some time ago browsers used show it as a message, but as the [modern specification](https://html.spec.whatwg.org/#unloading-documents) says, they shouldn't.
+由于历史原因，返回非空字符串也算作取消事件。在以前，浏览器通常将其显示为消息，但是根据 [modern specification](https://html.spec.whatwg.org/#unloading-documents) 所述，现在它们并不会显示了。
 
-Here's an example:
+这里有个例子：
 
 ```js run
 window.onbeforeunload = function() {
@@ -184,58 +183,59 @@ window.onbeforeunload = function() {
 };
 ```
 
-The behavior was changed, because some webmasters abused this event handler by showing misleading and annoying messages. So right now old browsers still may show it as a message, but aside of that -- there's no way to customize the message shown to the user.
+它的行为在某种意义上被改变了，因为一些站长通过显示误导性及恶意的信息滥用了这个事件处理器。所以，目前来看一些老旧的浏览器可能仍然显示为消息，但除此之外 —— 没有别的办法自定义显示给用户的消息。
 
 ## readyState
 
-What happens if we set the `DOMContentLoaded` handler after the document is loaded?
+如果在文档加载之后设置 `DOMContentLoaded` 事件处理器会发生什么呢？
 
-Naturally, it never runs.
+很自然地，它不会被运行。
 
-There are cases when we are not sure whether the document is ready or not. We'd like our function to execute when the DOM is loaded, be it now or later.
+在某些情况下，我们不确定文档是否已经准备就绪。当 DOM 加载完成时，我们想要执行一些函数，可能是立即执行也可能是稍后执行。
 
-The `document.readyState` property tells us about the current loading state.
+`document.readyState` 属性为我们提供了一些关于当前加载状态的信息。
 
-There are 3 possible values:
+它有三个可能的值：
 
-- `"loading"` -- the document is loading.
-- `"interactive"` -- the document was fully read.
-- `"complete"` -- the document was fully read and all resources (like images) are loaded too.
+- `“loading”` —— 文档正在被加载。
+- `“interactive”` —— 文档被全部读取。
+- `“complete”` —— 文档被全部读取，并且所有的资源（图像之类的）都被加载。
 
-So we can check `document.readyState` and setup a handler or execute the code immediately if it's ready.
+因此我们可以检查 `document.readyState` 并设置一个处理器，或在代码准备就绪时立即执行它。
 
-Like this:
+就像这样：
 
 ```js
 function work() { /*...*/ }
 
 if (document.readyState == 'loading') {
-  // loading yet, wait for the event
+  // 正在加载，等待事件
   document.addEventListener('DOMContentLoaded', work);
 } else {
-  // DOM is ready!
+  // DOM 已经准备就绪！
   work();
 }
 ```
 
-There's also `readystatechange` event that triggers when the state changes, so we can print all these states like this:
+还有一个 `readystatechange` 事件，当状态发生变化时触发，因此我们可以打印所有这些状态，就像这样：
 
 ```js run
-// current state
+// 当前状态
 console.log(document.readyState);
 
-// print state changes
+// 状态改变时打印它
 document.addEventListener('readystatechange', () => console.log(document.readyState));
 ```
 
-The `readystatechange` event is an alternative mechanics of tracking the document loading state, it appeared long ago. Nowadays, it is rarely used.
+`readystatechange` 事件是跟踪文档加载状态的另一种机制，它很早就存在了。现在则很少被使用。
 
-Let's see the full events flow for the completeness.
+但是为了完整起见，我们继续讨论一下它的全部事件。
 
-Here's a document with `<iframe>`, `<img>` and handlers that log events:
+这里有一个带有 `<iframe>`、`<img>` 和记录事件的处理程序的文档：
 
 ```html
 <script>
+  function log(text) { /* output the time and message */ }
   log('initial readyState:' + document.readyState);
 
   document.addEventListener('readystatechange', () => log('readyState:' + document.readyState));
@@ -252,9 +252,9 @@ Here's a document with `<iframe>`, `<img>` and handlers that log events:
 </script>
 ```
 
-The working example is [in the sandbox](sandbox:readystate).
+[在 sandbox](sandbox:readystate) 中的运行示例。
 
-The typical output:
+典型输出：
 1. [1] initial readyState:loading
 2. [2] readyState:interactive
 3. [2] DOMContentLoaded
@@ -263,23 +263,22 @@ The typical output:
 6. [4] readyState:complete
 7. [4] window onload
 
-The numbers in square brackets denote the approximate time of when it happens. Events labeled with the same digit happen approximately at the same time (+- a few ms).
-
-- `document.readyState` becomes `interactive` right before `DOMContentLoaded`. These two things actually mean the same.
-- `document.readyState` becomes `complete` when all resources (`iframe` and `img`) are loaded. Here we can see that it happens in about the same time as `img.onload` (`img` is the last resource) and `window.onload`. Switching to `complete` state means the same as `window.onload`. The difference is that `window.onload` always works after all other `load` handlers.
+方括号中的数字表示发生这种情况的大致时间。标记为相同数字的事件几乎是同时发生的（+- 几毫秒）。
 
+- `document.readyState` 在 `DOMContentLoaded` 之前会立即变成了 `interactive`。这两个事件的意义实际上是相同的。
+- 当所有资源（`iframe` 和 `img`）都被加载完成后，`document.readyState` 变成了 `complete`。这里我们可以发现，它大约发生在 `img.onload`（`img` 是最后的资源）和 `window.onload` 之间。转换到 `complete` 状态的意义与 `window.onload` 一致。区别在于 `window.onload` 在所有其他 `load` 处理器之后一直有效。
 
-## Summary
+## 总结
 
-Page load events:
+页面生命周期事件：
 
-- `DOMContentLoaded` event triggers on `document` when DOM is ready. We can apply JavaScript to elements at this stage.
-  - Script such as `<script>...</script>` or `<script src="..."></script>` block DOMContentLoaded, the browser waits for them to execute.
-  - Images and other resources may also still continue loading.
-- `load` event on `window` triggers when the page and all resources are loaded. We rarely use it, because there's usually no need to wait for so long.
-- `beforeunload` event on `window` triggers when the user wants to leave the page. If we cancel the event, browser asks whether the user really wants to leave (e.g we have unsaved changes).
-- `unload` event on `window` triggers when the user is finally leaving, in the handler we can only do simple things that do not involve delays or asking a user. Because of that limitation, it's rarely used. We can send out a network request with `navigator.sendBeacon`.
-- `document.readyState` is the current state of the document, changes can be tracked in the `readystatechange` event:
-  - `loading` -- the document is loading.
-  - `interactive` -- the document is parsed, happens at about the same time as `DOMContentLoaded`, but before it.
-  - `complete` -- the document and resources are loaded, happens at about the same time as `window.onload`, but before it.
+- 当 DOM 准备就绪时，`DOMContentLoaded` 事件就会在 `document` 上触发。在这个阶段，我们可以将 JavaScript 应用于元素。
+  - 诸如 `<script>...</script>` 或者 `<script src="..."></script>` 会阻塞 DOMContentLoaded，浏览器等待它们执行结束。
+  - 图像和其他资源仍然可以继续被加载。
+- 当页面和所有资源被加载时，`window` 上的 `load` 事件会被触发。我们很少使用它，因为通常没有必要去等待那么久。
+- 当用户想要离开页面时，`window` 上的 `beforeunload` 事件会被触发。如果我们取消这个事件，浏览器会询问用户是否真的要离开（比如有未保存的内容）。
+- 当用户最终离开时，`window` 上的 `unload` 事件会被触发。在处理器中，我们只能做一些不会涉及到延迟或询问用户的简单事情。正是由于这个限制，它很少被使用。我们可以用 `navigator.sendBeacon` 来发送网络请求。
+- `document.readyState` 是文档的当前状态，可以在 `readystatechange` 事件中跟踪状态变更：
+  - `loading` —— 文档正在被加载。
+  - `interactive` —— 文档被解析，大概是与 `DOMContentLoaded` 同时发生，而不是在它之前发生。
+  - `complete` —— 文档和资源被加载，大概是与 `window.onload` 同时发生，而不是在它之前发生。
diff --git a/2-ui/5-loading/03-onload-onerror/1-load-img-callback/solution.md b/2-ui/5-loading/03-onload-onerror/1-load-img-callback/solution.md
index 931446f3fd..772aedf0d2 100644
--- a/2-ui/5-loading/03-onload-onerror/1-load-img-callback/solution.md
+++ b/2-ui/5-loading/03-onload-onerror/1-load-img-callback/solution.md
@@ -1,6 +1,6 @@
 
-The algorithm:
-1. Make `img` for every source.
-2. Add `onload/onerror` for every image.
-3. Increase the counter when either `onload` or `onerror` triggers.
-4. When the counter value equals to the sources count -- we're done: `callback()`.
+算法：
+1. 为每个资源制作 `img`。
+2. 为每个 image 添加 `onload/onerror`。
+3. 在 `onload` 或 `onerror` 被触发时增加计数器。
+4. 当计数器值等于资源值时 —— 结束：`callback()`。
diff --git a/2-ui/5-loading/03-onload-onerror/1-load-img-callback/task.md b/2-ui/5-loading/03-onload-onerror/1-load-img-callback/task.md
index 38ce078dd3..c3be4cd24c 100644
--- a/2-ui/5-loading/03-onload-onerror/1-load-img-callback/task.md
+++ b/2-ui/5-loading/03-onload-onerror/1-load-img-callback/task.md
@@ -2,22 +2,22 @@ importance: 4
 
 ---
 
-# Load images with a callback
+# 用回调函数加载 images
 
-Normally, images are loaded when they are created. So when we add `<img>` to the page, the user does not see the picture immediately. The browser needs to load it first.
+通常，图像在被创建时才会被加载，因此当我们在页面中添加 `<img>` 时，用户不会立即看到图像。浏览器首先需要加载它。
 
-To show an image immediately, we can create it "in advance", like this:
+我们可以像这样“提前”创建它来立即显示图像：
 
 ```js
 let img = document.createElement('img');
 img.src = 'my.jpg';
 ```
 
-The browser starts loading the image and remembers it in the cache. Later, when the same image appears in the document (no matter how), it shows up immediately.
+浏览器开始加载图像然后保存在缓存中。之后，当相同图像出现在文档中时（无论怎样），它会立即显示。
 
-**Create a function `preloadImages(sources, callback)` that loads all images from the array `sources` and, when ready, runs `callback`.**
+**创建一个函数，用来从 `source` 数组中加载所有图像，并在准备就绪时运行 `callback` 的 `preloadImages(sources, callback)` 。**
 
-For instance, this will show an `alert` after the images are loaded:
+例如，这将在加载图像之后显示一个 `alert`：
 
 ```js
 function loaded() {
@@ -27,10 +27,10 @@ function loaded() {
 preloadImages(["1.jpg", "2.jpg", "3.jpg"], loaded);
 ```
 
-In case of an error, the function should still assume the picture "loaded".
+如果出现错误，函数仍会认为图像已经“被加载”。
 
-In other words, the `callback` is executed when all images are either loaded or errored out.
+换句话说，当所有图像被加载或出现错误输出时，`callback` 都会被执行。
 
-The function is useful, for instance, when we plan to show a gallery with many scrollable images, and want to be sure that all images are loaded.
+比如，当我们计划显示一个包含许多图像的可滚动图库，并希望确保所有的图像都被加载时，这个函数是非常有用的。
 
-In the source document you can find links to test images, and also the code to check whether they are loaded or not. It should output `300`.
+在源文档中，你可以找到指向测试图像的链接，以及检查它们是否已被加载的代码。它应该输出 `300`。
diff --git a/2-ui/5-loading/03-onload-onerror/article.md b/2-ui/5-loading/03-onload-onerror/article.md
index ef1f5fe152..fc60dabca2 100644
--- a/2-ui/5-loading/03-onload-onerror/article.md
+++ b/2-ui/5-loading/03-onload-onerror/article.md
@@ -1,17 +1,17 @@
-# Resource loading: onload and onerror
+# 资源加载：onload 和 onerror
 
-The browser allows to track the loading of external resources -- scripts, iframes, pictures and so on.
+浏览器允许跟踪外部资源的加载 —— 脚本、iframes、图像等。
 
-There are two events for it:
+它有两个事件：
 
-- `onload` -- successful load,
-- `onerror` -- an error occurred.
+- `onload` —— 成功加载，
+- `onerror` —— 发生异常。
 
-## Loading a script
+## 加载脚本
 
-Let's say we need to load a third-party script and call a function that resides there.
+假设我们需要调用属于第三方脚本的函数。
 
-We can load it dynamically, like this:
+我们可以像这样动态加载：
 
 ```js
 let script = document.createElement('script');
@@ -20,68 +20,68 @@ script.src = "my.js";
 document.head.append(script);
 ```
 
-...But how to run the function that is declared inside that script? We need to wait until the script loads, and only then we can call it.
+……但如何运行声明在脚本中的函数？我们需要等到脚本被加载后才能调用它。
 
 ```smart
-For our own scripts we could use [JavaScript modules](info:modules) here, but they are not widely adopted by third-party libraries.
+对于我们自己的脚本，可以使用 [JavaScript modules](info:modules)，但它们并没有被第三方库广泛采用。
 ```
 
 ### script.onload
 
-The main helper is the `load` event. It triggers after the script was loaded and executed.
+主要得力于 `load` 事件。它在脚本被加载和执行后才会触发。
 
-For instance:
+例如：
 
 ```js run untrusted
 let script = document.createElement('script');
 
-// can load any script, from any domain
+// 可以从任意域名加载任意脚本
 script.src = "https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.3.0/lodash.js"
 document.head.append(script);
 
 *!*
 script.onload = function() {
-  // the script creates a helper function "_"
-  alert(_); // the function is available
+  // 脚本创建了一个辅助函数“_”
+  alert(_); // 函数可用
 };
 */!*
 ```
 
-So in `onload` we can use script variables, run functions etc.
+因此，在 `onload` 中我们可以使用脚本中的变量、运行函数等。
 
-...And what if the loading failed? For instance, there's no such script (error 404) or the server or the server is down (unavailable).
+……如果加载失败怎么办？比如，没有这样的脚本（错误 404）或者服务器宕机（不可用）。
 
 ### script.onerror
 
-Errors that occur during the loading of the script can be tracked on `error` event.
+发生在脚本加载期间的错误可以在 `error` 事件上进行追踪。
 
-For instance, let's request a script that doesn't exist:
+比如，我们请求一个不存在的脚本：
 
 ```js run
 let script = document.createElement('script');
-script.src = "https://example.com/404.js"; // no such script
+script.src = "https://example.com/404.js"; // 没有这样的脚本
 document.head.append(script);
 
 *!*
 script.onerror = function() {
-  alert("Error loading " + this.src); // Error loading https://example.com/404.js
+  alert("Error loading " + this.src); // 加载 https://example.com/404.js 发生错误
 };
 */!*
 ```
 
-Please note that we can't get HTTP error details here. We don't know was it error 404 or 500 or something else. Just that the loading failed.
+请注意，我们无法在这里获取更多 HTTP 错误细节。我们不知道错误是 404 还是 500 或者其他情况，只知道是加载失败了。
 
 ```warn
-Events `onload`/`onerror` track only the loading itself.
+`onload`/`onerror` 事件仅仅跟踪加载本身。
 
-Errors during script processing and execution are out of the scope of these events. To track script errors, one can use `window.onerror` global handler.
+跟踪脚本处理和执行期间的错误超出了这些事件的范围。如果要追踪脚本错误，可以使用 `window.onerror` 全局处理器。
 ```
 
-## Other resources
+## 其他资源
 
-The `load` and `error` events also work for other resources, basically for any resource that has an external `src`.
+`load` 和 `error` 事件也适用于几乎任何具有外部 `src` 的资源。
 
-For example:
+例如：
 
 ```js run
 let img = document.createElement('img');
@@ -96,30 +96,30 @@ img.onerror = function() {
 };
 ```
 
-There are some notes though:
+但也有一些注意事项：
 
-- Most resources start loading when they are added to the document. But `<img>` is an exception. It starts loading when it gets an src `(*)`.
-- For `<iframe>`, the `iframe.onload` event triggers when the iframe loading finished, both for successful load and in case of an error.
+- 对于大部分资源来说，当他们被添加到文档时就开始加载。但是 `<img>` 是个例外。它要等到获取 src `(*)` 属性后才开始加载。
+- 对于 `<iframe>` 来说，只要 iframe 加载完成，不论成功还是失败，`iframe.onload` 事件都会触发，
 
-That's for historical reasons.
+这是出于历史遗留原因。
 
-## Crossorigin policy
+## 跨域策略
 
-There's a rule: scripts from one site can't access contents of the other site. So, e.g. a script at `https://facebook.com` can't read the user's mailbox at `https://gmail.com`.
+这里有个规则：来自一个站点的脚本无法访问其他站点的内容。即 `https://facebook.com` 中的脚本不能获取 `https://gmail.com` 中的用户邮箱。
 
-Or, to be more precise, one origin (domain/port/protocol triplet) can't access the content from another one. So even if we have a subdomain, or just another port, these are different origins, no access to each other.
+或者，更确切地说，一个源（domain/port/protocol 三者）不能获取另外一个源中的内容。因此，即使我们有一个子域名，或者仅仅是另外一个端口，这都是不同的源，彼此不能互相访问。
 
-This rule also affects resources from other domains.
+这个规则同样适用于其他域中的资源。
 
-If we're using a script from another domain, and there's an error in it, we can't get error details.
+如果我们需要使用来自其他域名的脚本，并且脚本里面存在错误，那么我们就不能获取错误信息。
 
-For example, let's take a script with a single (bad) function call:
+例如，我们调用脚本中一个（错误）函数：
 ```js
 // 📁 error.js
 noSuchFunction();
 ```
 
-Now load it from our domain:
+现在从我们的域名中加载它：
 
 ```html run height=0
 <script>
@@ -130,14 +130,14 @@ window.onerror = function(message, url, line, col, errorObj) {
 <script src="/article/onload-onerror/crossorigin/error.js"></script>
 ```
 
-We can see a good error report, like this:
+我们可以看到一个很好的错误报告，就像这样：
 
 ```
 Uncaught ReferenceError: noSuchFunction is not defined
 https://javascript.info/article/onload-onerror/crossorigin/error.js, 1:1
 ```
 
-Now let's load the same script from another domain:
+现在，再从其他域名中加载这个脚本：
 
 ```html run height=0
 <script>
@@ -148,40 +148,40 @@ window.onerror = function(message, url, line, col, errorObj) {
 <script src="https://cors.javascript.info/article/onload-onerror/crossorigin/error.js"></script>
 ```
 
-The report is different, like this:
+错误报告与上面不同，就像这样：
 
 ```
 Script error.
 , 0:0
 ```
 
-Details may vary depending on the browser, but the idea is same: any information about the internals of a script is hidden. Exactly because it's from another domain.
+错误细节可能因浏览器而异，但是原理是相同的：任何有关脚本内部的信息都是不可见的。确切来说是因为它来自于其他域。
 
-Why do we need the details?
+我们为什么需要细节信息？
 
-There are many services (and we can build our own) that listen to `window.onerror`, save errors at the server and provide an interface to access and analyze them. That's great, as we can see real errors, triggered by our users. But we can't see any error information for scripts from other domains.
+因为有很多服务（我们也可以自己建立）监听 `window.onerror`，在服务器上保存错误信息，并分析它们，以提供用户相应的错误页面。这很棒，因为我们可以看到由用户触发的真实错误。但是我们不能获得来自其他域名的脚本的任何错误信息。
 
-Similar cross-origin policy (CORS) is enforced for other types of resources as well.
+类似的跨源策略（CORS）也适用于其他类型资源。
 
-**To allow cross-origin access, we need `crossorigin` attribute, plus the remote server must provide special headers.**
+**要允许跨域访问，我们需要 `crossorigin` 属性，同样对于服务器也需要提供特殊的响应头。**
 
-There are three levels of cross-origin access:
+这里有三个级别的跨源访问：
 
-1. **No `crossorigin` attribute** -- access prohibited.
-2. **`crossorigin="anonymous"`** -- access allowed if the server responds with the header `Access-Control-Allow-Origin` with `*` or our origin. Browser does not send authorization information and cookies to remote server.
-3. **`crossorigin="use-credentials"`** -- access allowed if the server sends back the header `Access-Control-Allow-Origin` with our origin and `Access-Control-Allow-Credentials: true`.  Browser sends authorization information and cookies to remote server.
+1. **无 `crossorigin` 属性*** —— 禁止访问。
+2. **`crossorigin="anonymous"`** —— 如果服务器的响应头中提供了 `Access-Control-Allow-Origin` 为 `*` 或者为我们的源，那么就可以访问。浏览器不会将授权信息和 cookies 发送到远程服务器。
+3. **`crossorigin="use-credentials"`** —— 如果服务器的响应头提供了 `Access-Control-Allow-Origin` 为我们的源，且提供了 `Access-Control-Allow-Credentials: true`，那么我们就可以访问。浏览器此时会将授权信息和 cookies 发送到远程服务器。
 
 ```smart
-You can read more about cross-origin access in the chapter <info:fetch-crossorigin>. It describes `fetch` method for network requests, but the policy is exactly the same.
+你可以在 <info:fetch-crossorigin> 中阅读更多关于跨源访问的信息。这里虽然它是以 `fetch` 方法作为网络请求的，但策略都是相同的。
 
-Such thing as "cookies" is out of our current scope, but you can read about them in the chapter <info:cookie>.
+诸如“cookies”这类的内容超出了本章的范围，你可以在 <info:cookie> 章节获取到关于它的更多信息。
 ```
 
-In our case, we didn't have any crossorigin attribute. So the cross-origin access was prohibited. Let's add it.
+在我们的的例子中没有任何 crossorigin 属性。因此禁止跨域访问。让我们来加上它吧。
 
-We can choose between `"anonymous"` (no cookies sent, one server-side header needed) and `"use-credentials"` (sends cookies too, two server-side headers needed).
+我们可以选择“anonymous”（不会发送 cookies，但是需要一个服务端响应头）或者“use-credentials”（发送 cookes，需要设置两个服务端响应头）。
 
-If we don't care about cookies, then `"anonymous"` is a way to go:
+如果我们不关心“cookies”，那么可以使用`“anonymous”`：
 
 ```html run height=0
 <script>
@@ -192,15 +192,15 @@ window.onerror = function(message, url, line, col, errorObj) {
 <script *!*crossorigin="anonymous"*/!* src="https://cors.javascript.info/article/onload-onerror/crossorigin/error.js"></script>
 ```
 
-Now, assuming that the server provides `Access-Control-Allow-Origin` header, everything's fine. We have the full error report.
+现在，假设服务器提供 `Access-Control-Allow-Origin` 头，一切都正常。我们有完整的错误报告。
 
-## Summary
+## 总结
 
-Images `<img>`, external styles, scripts and other resources provide `load` and `error` events to track their loading:
+`<img>` 图像、外部样式表、脚本和其他资源都提供了 `load` 和 `error` 事件来追踪它们的加载：
 
-- `load` triggers on a successful load,
-- `error` triggers on a failed load.
+- `load` 在成功加载时被触发。
+- `error` 在加载失败时被触发。
 
-The only exception is `<iframe>`: for historical reasons it always triggers `load`, for any load completion, even if the page is not found.
+只有 `<iframe>` 特殊：出于历史原因，不管加载成功还是失败，即使页面没有被找到，它都会触发 `load` 事件。
 
-The `readystatechange` event also works for resources, but is rarely used, because `load/error` events are simpler.
+`readystatechange` 事件也适用于资源，但很少被使用，因为 `load/error` 事件更简单。