Fixed unclosed HTML tag

Author: sevi418

src/content/10/zh/part10c.md

@@ -70,12 +70,12 @@ const fetchMovies = async () => {
  接下来，让我们在实践中尝试Fetch API。Rate-repository-api 服务器提供了一个端点，用于返回一个分页的已审核仓库的列表。一旦服务器运行，你应该能够访问[http://localhost:5000/api/repositories](http://localhost:5000/api/repositories)这个端点。数据是以常见的[基于游标的分页格式](https://graphql.org/learn/pagination/)分页的。实际的存储库数据在<i>node</i>键后面的<i>edges</i>阵列中。
 
 <!-- Unfortunately, we can't access the server directly in our application by using the <i>http://localhost:5000/api/repositories</i> URL. To make a request to this endpoint in our application we need to access the server using its IP address in its local network. To find out what it is, open the Expo development tools by running <em>npm start</em>. In the development tools you should be able to see an URL starting with <i>exp://</i> above the QR code:-->
- 不幸的是，我们不能通过使用<i>http://localhost:5000/api/repositories</i> URL在我们的应用中直接访问该服务器。为了在我们的应用中向这个端点发出请求，我们需要使用其本地网络中的IP地址访问服务器。要知道它是什么，通过运行<em>npm start</em>打开Expo开发工具。在开发工具中，你应该能够看到二维码上面有一个以<i>exp://<i>开头的URL。
+ 不幸的是，我们不能通过使用<i>http://localhost:5000/api/repositories</i> URL在我们的应用中直接访问该服务器。为了在我们的应用中向这个端点发出请求，我们需要使用其本地网络中的IP地址访问服务器。要知道它是什么，通过运行<em>npm start</em>打开Expo开发工具。在开发工具中，你应该能够看到二维码上面有一个以<i>exp://</i>开头的URL。
 
 ![Development tools](../../images/10/10.png)
 
 <!-- Copy the IP address between the <i>exp://</i> and <i>:</i>, which is in this example <i>192.168.100.16</i>. Construct an URL in format <i>http://<IP_ADDRESS>:5000/api/repositories</i> and open it in the browser. You should see the same response as you did with the <i>localhost</i> URL.-->
- 复制<i>exp://<i>和<i>:</i>之间的IP地址，在这个例子中是<i>192.168.100.16</i>。构建一个格式为<i>http://<IP_ADDRESS>:5000/api/repositories</i>的URL，并在浏览器中打开它。你应该看到与<i>localhost</i> URL相同的响应。
+ 复制<i>exp://</i>和<i>:</i>之间的IP地址，在这个例子中是<i>192.168.100.16</i>。构建一个格式为<i>http://<IP_ADDRESS>:5000/api/repositories</i>的URL，并在浏览器中打开它。你应该看到与<i>localhost</i> URL相同的响应。
 
 <!-- Now that we know the end point's URL let's use the actual server-provided data in our reviewed repositories list. We are currently using mock data stored in the <em>repositories</em> variable. Remove the <em>repositories</em> variable and replace the usage of the mock data with this piece of code in the <i>RepositoryList.jsx</i> file in the <i>components</i> directory:-->
  现在我们知道了端点的URL，让我们在审查的存储库列表中使用服务器提供的实际数据。我们目前正在使用存储在<em>repositories</em>变量中的模拟数据。删除<em>repositories</em>变量，用<i>components</i>目录下的<i>RepositoryList.jsx</i>文件中的这段代码替换模拟数据的使用。

src/content/11/zh/part11a.md

@@ -28,7 +28,7 @@ lang: zh
  我们已经使用GitHub来存储我们的源代码，但当我们在一个有更多开发者的团队中工作时，会发生什么？
 
 <!-- Many problems may arise when several developers are involved. The software might work just fine on <i>my computer</i>, but maybe some of the other developers are using a different operating system or different library versions. It is not uncommon that a code works just fine in one developer's machine but another developer can not even get it started. This is often called the "works on my machine" problem.-->
- 当几个开发人员参与时，可能会出现许多问题。该软件可能在<i>我的电脑上工作得很好，但也许其他一些开发者使用的是不同的操作系统或不同的库版本。一个代码在一个开发者的机器上工作得很好，但另一个开发者甚至无法启动它，这种情况并不罕见。这通常被称为 "在我的机器上工作 "的问题。
+ 当几个开发人员参与时，可能会出现许多问题。该软件可能在<i>我的电脑上</i>工作得很好，但也许其他一些开发者使用的是不同的操作系统或不同的库版本。一个代码在一个开发者的机器上工作得很好，但另一个开发者甚至无法启动它，这种情况并不罕见。这通常被称为 "在我的机器上工作 "的问题。
 
 <!-- There are also more involved problems. If two developers are both working on changes and they haven't decided on a way to deploy to production, whose changes get deployed? How would it be possible to prevent one developer's changes from overwriting another's?-->
  也有一些更复杂的问题。如果两个开发者都在做修改，而他们还没有决定如何部署到生产中，那么谁的修改会被部署？怎样才能防止一个开发者的修改覆盖另一个开发者的修改？
@@ -58,7 +58,7 @@ lang: zh
 #### Pull request
 
 <!-- In GitHub merging a branch back to the main branch of software is quite often happening using a mechanism called [pull request](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-pull-requests), where the developer who has done some changes is requesting the changes to be merged to the main branch. Once the pull request, or PR as it's often called, is made or <i>opened</i>, another developer checks that all is ok and <i>merges</i> the PR.-->
- 在GitHub中，将一个分支合并到软件的主干分支，通常是通过一个叫做[pull request](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-pull-requests)的机制实现的，在这个机制中，做了一些修改的开发者要求将这些修改合并到主干分支。一旦提出了拉动请求，也就是通常所说的PR，或者<i>打开了<i>，另一个开发者就会检查是否一切正常，然后<i>合并</i>PR。
+ 在GitHub中，将一个分支合并到软件的主干分支，通常是通过一个叫做[pull request](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-pull-requests)的机制实现的，在这个机制中，做了一些修改的开发者要求将这些修改合并到主干分支。一旦提出了拉动请求，也就是通常所说的PR，或者<i>打开了</i>，另一个开发者就会检查是否一切正常，然后<i>合并</i>PR。
 
 <!-- If you have proposed changes to the material of this course, you have already made a pull request!-->
  如果你对本课程的材料提出了修改意见，你就已经提出了一个拉动请求!

src/content/11/zh/part11d.md

@@ -331,7 +331,7 @@ jobs:
  看看工作流日志中会打印出什么!
 
 <!-- Note that you can access the commits and commit messages <i>only when pushing or merging to the main branch</i>, so for pull requests the <code>github.event.commits</code> is empty. It is anyway not needed, since we want to skip the step altogether for pull requests.-->
- 注意，你只能在推送或合并到主分支时访问提交和提交信息<i>，所以对于拉取请求，<code>github.event.commits</code>是空的。反正也不需要，因为我们想对拉取请求完全跳过这一步。
+ 注意，你只能在<i>推送或合并到主分支时访问提交和提交信息</i>，所以对于拉取请求，<code>github.event.commits</code>是空的。反正也不需要，因为我们想对拉取请求完全跳过这一步。
 
 <!-- You most likely need functions [contains](https://docs.github.com/en/actions/learn-github-actions/expressions#contains) and [join](https://docs.github.com/en/actions/learn-github-actions/expressions#join) for your if condition.-->
  你很可能需要函数 [contains](https://docs.github.com/en/actions/learn-github-actions/expressions#contains) 和 [join](https://docs.github.com/en/actions/learn-github-actions/expressions#join) 作为你的if条件。

src/content/12/zh/part12a.md

@@ -36,7 +36,7 @@ lang: zh
 尽管应用在你的机器上运行得很好，但它就是不能在服务器上运行，这种情况并不罕见。这可能是由于某些依赖性的缺失或环境的其他差异。在这里，容器是一个很好的解决方案，因为你可以在你的机器和服务器上的同一执行环境中运行应用。这并不完美：不同的硬件可能是一个问题，但你可以限制环境之间的差异。
 
 <!-- Sometimes you may hear about the <i>"Works in my container"</i> issue. The phrase describes a situation in which the application works fine in a container running on your machine but breaks when the container is started on a server. The phrase is a play on the infamous <i>"Works on my machine"</i> issue, which containers are often promised to solve. The situation also is most likely a usage error.-->
- 有时你可能会听到<i>"在我的容器中工作"<i>问题。这句话描述了这样一种情况：应用在你的机器上运行的容器中工作正常，但当容器在服务器上启动时就会中断。这句话是对臭名昭著的<i>"在我的机器上工作"</i>问题的一种戏谑，容器通常被承诺解决这个问题。这种情况也很可能是一个使用错误。
+ 有时你可能会听到<i>"在我的容器中工作"</i>问题。这句话描述了这样一种情况：应用在你的机器上运行的容器中工作正常，但当容器在服务器上启动时就会中断。这句话是对臭名昭著的<i>"在我的机器上工作"</i>问题的一种戏谑，容器通常被承诺解决这个问题。这种情况也很可能是一个使用错误。
 
 ### About this part ###
 
@@ -76,7 +76,7 @@ lang: zh
 ### Submitting exercises and earning credits ###
 
 <!-- Submit the exercises via the [submissions system](https://studies.cs.helsinki.fi/stats/) just like in the previous parts. Exercises in this part are submitted <i>to its [own course instance](https://studies.cs.helsinki.fi/stats/courses/fs-containers)</i>.-->
- 通过[提交系统](https://studies.cs.helsinki.fi/stats/)提交练习，就像在前面的部分一样。这一部分的练习被提交<i>到其[自己的课程实例](https://studies.cs.helsinki.fi/stats/courses/fs-containers)<i>。
+ 通过[提交系统](https://studies.cs.helsinki.fi/stats/)提交练习，就像在前面的部分一样。这一部分的练习被提交<i>到其[自己的课程实例](https://studies.cs.helsinki.fi/stats/courses/fs-containers)</i>。
 
 <!-- Completing this part on containers will get you 1 credit. Note that you need to do all the exercises for earning the credit or the certificate.-->
  在集装箱上完成这部分内容将得到1个学分。注意，你需要做所有的练习来获得学分或证书。

src/content/12/zh/part12b.md

@@ -423,7 +423,7 @@ services:
  上面定义的两个第一环境变量的含义在Docker Hub页面上有解释。
 
 <!-- > <i>These variables, used in conjunction, create a new user and set that user's password. This user is created in the admin authentication database and given the role of root, which is a "superuser" role.</i>-->
- > <i>这些变量结合起来使用，可以创建一个新的用户并设置该用户的密码。这个用户在管理员认证数据库中被创建，并被赋予root的角色，这是一个 "超级用户 "角色。
+ > <i>这些变量结合起来使用，可以创建一个新的用户并设置该用户的密码。这个用户在管理员认证数据库中被创建，并被赋予root的角色，这是一个 "超级用户 "角色。</i>
 
 <!-- The last environment variable *MONGO\_INITDB\_DATABASE* will tell MongoDB to create a database with that name.-->
  最后一个环境变量*MONGO\_INITDB\_DATABASE*将告诉MongoDB以该名称创建一个数据库。
@@ -937,7 +937,7 @@ services:
  除了对键和值的GET、SET和DEL操作外，Redis还可以做很多事情。例如，它可以自动过期键，当Redis被用作缓存时，这是一个非常有用的功能。
 
 <!-- Redis can also be used to implement so called [publish-subscribe](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern) (or PubSub) pattern that is a asynchronous communication mechanism for distributed applications. In this scenario Redis works as a <i>message broker</i> between two or more applications. Some of the applications are <i>publishing</i> messages by sending those to Redis, that on arrival of a message, informs the parties that have <i>subscribed</i> to those messages.-->
- Redis也可以用来实现所谓的[发布-订阅](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern)(或PubSub)模式，这是一种分布式应用的异步通信机制。在这种情况下，Redis作为两个或多个应用之间的<i>消息代理</i>工作。一些应用通过向Redis发送消息来发布<i>消息，当消息到达时，Redis会通知已经<i>订阅</i>这些消息的各方。
+ Redis也可以用来实现所谓的[发布-订阅](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern)(或PubSub)模式，这是一种分布式应用的异步通信机制。在这种情况下，Redis作为两个或多个应用之间的<i>消息代理</i>工作。一些应用通过向Redis发送消息来<i>发布</i>消息，当消息到达时，Redis会通知已经<i>订阅</i>这些消息的各方。
 
 </div>
 
@@ -951,6 +951,6 @@ services:
  检查数据是否默认不被持久化：在运行_docker-compose -f docker-compose.dev.yml down_和_docker-compose -f docker-compose.dev.yml up_之后，计数器值被重置为0。
 
 <!-- Then create a volume for Redis data (by modifying <i>todo-app/todo-backend/docker-compose.dev.yml </i>) and make sure that the data survives after running _docker-compose -f docker-compose.dev.yml down_ and _docker-compose -f docker-compose.dev.yml up_.-->
- 然后为Redis数据创建一个卷（通过modifying <i>todo-app/todo-backend/docker-compose.dev.yml <i>），并确保数据在运行_docker-compose -f docker-compose.dev.yml down_和_docker-compose -f docker-compose.dev.yml up_之后仍然存在。
+ 然后为Redis数据创建一个卷（通过modifying <i>todo-app/todo-backend/docker-compose.dev.yml </i>），并确保数据在运行_docker-compose -f docker-compose.dev.yml down_和_docker-compose -f docker-compose.dev.yml up_之后仍然存在。
 
 </div>

src/content/12/zh/part12c.md

@@ -437,7 +437,7 @@ services:
  接下来，我们将在我们的docker-compose.yml中添加一个[反向代理](https://en.wikipedia.org/wiki/Reverse_proxy)。根据维基百科的说法
 
 <!-- > <i>A reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client, appearing as if they originated from the reverse proxy server itself.</i>-->
-> <i>反向代理是一种代理服务器，它代表客户从一个或多个服务器中检索资源。这些资源然后被返回给客户，看起来就像它们来自反向代理服务器本身。
+> <i>反向代理是一种代理服务器，它代表客户从一个或多个服务器中检索资源。这些资源然后被返回给客户，看起来就像它们来自反向代理服务器本身。</i>
 
 <!-- So in our case, the reverse proxy will be the single point of entry to our application, and the final goal will be to set both the React frontend and the Express backend behind the reverse proxy.-->
 所以在我们的案例中，反向代理将是我们应用的单一入口点，而最终的目标是将React前端和Express后端都设置在反向代理后面。