New Crowdin updates

locale/en/about/governance.md

@@ -11,23 +11,17 @@ The Node.js project follows a [Consensus Seeking][] decision making model.
 
 ## Collaborators
 
-The [nodejs/node][] core GitHub repository is maintained by the Collaborators
-who are added by the Technical Steering Committee ([TSC][]) on an ongoing basis.
+The [nodejs/node][] core GitHub repository is maintained by the Collaborators who are added by the Technical Steering Committee ([TSC][]) on an ongoing basis.
 
-Individuals making significant and valuable contributions are made Collaborators
-and given commit-access to the project. These individuals are identified by the
-TSC and their nomination is discussed with the existing Collaborators.
+Individuals making significant and valuable contributions are made Collaborators and given commit-access to the project. These individuals are identified by the TSC and their nomination is discussed with the existing Collaborators.
 
 For the current list of Collaborators, see the project's [README.md][].
 
 A guide for Collaborators is maintained at [collaborator-guide.md][].
 
 ## Top Level Committees
 
-The project is governed jointly by the [Technical Steering Committee (TSC)][]
-which is responsible for high-level guidance of the project, and the
-[Community Committee (CommComm)][] which is responsible for guiding and
-extending the Node.js community.
+The project is governed jointly by the [Technical Steering Committee (TSC)][] which is responsible for high-level guidance of the project, and the [Community Committee (CommComm)][] which is responsible for guiding and extending the Node.js community.
 
 [collaborator-guide.md]: https://github.com/nodejs/node/blob/master/doc/guides/collaborator-guide.md
 [Community Committee (CommComm)]: https://github.com/nodejs/community-committee/blob/master/Community-Committee-Charter.md

locale/en/about/index.md

@@ -6,10 +6,7 @@ trademark: Trademark
 
 # About Node.js®
 
-As an asynchronous event-driven JavaScript runtime, Node.js is designed to build
-scalable network applications. In the following "hello world" example, many
-connections can be handled concurrently. Upon each connection, the callback is
-fired, but if there is no work to be done, Node.js will sleep.
+As an asynchronous event-driven JavaScript runtime, Node.js is designed to build scalable network applications. In the following "hello world" example, many connections can be handled concurrently. Upon each connection, the callback is fired, but if there is no work to be done, Node.js will sleep.
 
 ```javascript
 const http = require('http');
@@ -28,39 +25,17 @@ server.listen(port, hostname, () => {
 });
 ```
 
-This is in contrast to today's more common concurrency model, in which OS threads
-are employed. Thread-based networking is relatively inefficient and very
-difficult to use. Furthermore, users of Node.js are free from worries of
-dead-locking the process, since there are no locks. Almost no function in
-Node.js directly performs I/O, so the process never blocks except when the I/O is performed using
-synchronous methods of Node.js standard library. Because nothing blocks, scalable systems are very
-reasonable to develop in Node.js.
+This is in contrast to today's more common concurrency model, in which OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. Furthermore, users of Node.js are free from worries of dead-locking the process, since there are no locks. Almost no function in Node.js directly performs I/O, so the process never blocks except when the I/O is performed using synchronous methods of Node.js standard library. Because nothing blocks, scalable systems are very reasonable to develop in Node.js.
 
-If some of this language is unfamiliar, there is a full article on
-[Blocking vs. Non-Blocking][].
+If some of this language is unfamiliar, there is a full article on [Blocking vs. Non-Blocking][].
 
 ---
 
-Node.js is similar in design to, and influenced by, systems like Ruby's
-[Event Machine][] and Python's [Twisted][]. Node.js takes the event model a bit
-further. It presents an [event loop][] as a runtime construct instead of as a library. In other systems,
-there is always a blocking call to start the event-loop.
-Typically, behavior is defined through callbacks at the beginning of a script, and
-at the end a server is started through a blocking call like `EventMachine::run()`.
-In Node.js, there is no such start-the-event-loop call. Node.js simply enters the event loop after executing the input script. Node.js
-exits the event loop when there are no more callbacks to perform. This behavior
-is like browser JavaScript — the event loop is hidden from the user.
+Node.js is similar in design to, and influenced by, systems like Ruby's [Event Machine][] and Python's [Twisted][]. Node.js takes the event model a bit further. It presents an [event loop][] as a runtime construct instead of as a library. In other systems, there is always a blocking call to start the event-loop. Typically, behavior is defined through callbacks at the beginning of a script, and at the end a server is started through a blocking call like `EventMachine::run()`. In Node.js, there is no such start-the-event-loop call. Node.js simply enters the event loop after executing the input script. Node.js exits the event loop when there are no more callbacks to perform. This behavior is like browser JavaScript — the event loop is hidden from the user.
 
-HTTP is a first-class citizen in Node.js, designed with streaming and low
-latency in mind. This makes Node.js well suited for the foundation of a web
-library or framework.
+HTTP is a first-class citizen in Node.js, designed with streaming and low latency in mind. This makes Node.js well suited for the foundation of a web library or framework.
 
-Node.js being designed without threads doesn't mean you can't take
-advantage of multiple cores in your environment. Child processes can be spawned
-by using our [`child_process.fork()`][] API, and are designed to be easy to
-communicate with. Built upon that same interface is the [`cluster`][] module,
-which allows you to share sockets between processes to enable load balancing
-over your cores.
+Node.js being designed without threads doesn't mean you can't take advantage of multiple cores in your environment. Child processes can be spawned by using our [`child_process.fork()`][] API, and are designed to be easy to communicate with. Built upon that same interface is the [`cluster`][] module, which allows you to share sockets between processes to enable load balancing over your cores.
 
 [Blocking vs. Non-Blocking]: /en/docs/guides/blocking-vs-non-blocking/
 [`child_process.fork()`]: https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

locale/en/about/releases.md

@@ -19,7 +19,4 @@ schedule-footer: Dates are subject to change.
 
 # Releases
 
-Major Node.js versions enter _Current_ release status for six months, which gives library authors time to add support for them.
-After six months, odd-numbered releases (9, 11, etc.) become unsupported, and even-numbered releases (10, 12, etc.) move to _Active LTS_ status and are ready for general use.
-_LTS_ release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months.
-Production applications should only use _Active LTS_ or _Maintenance LTS_ releases.
+Major Node.js versions enter _Current_ release status for six months, which gives library authors time to add support for them. After six months, odd-numbered releases (9, 11, etc.) become unsupported, and even-numbered releases (10, 12, etc.) move to _Active LTS_ status and are ready for general use. _LTS_ release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months. Production applications should only use _Active LTS_ or _Maintenance LTS_ releases.

locale/en/about/resources.md

@@ -9,8 +9,7 @@ title: Logos and Graphics
 
 Please review the [trademark policy](/en/about/trademark/) for information about permissible use of Node.js® logos and marks.
 
-Guidelines for the visual display of the Node.js mark are described in
-the [Visual Guidelines](/static/documents/foundation-visual-guidelines.pdf).
+Guidelines for the visual display of the Node.js mark are described in the [Visual Guidelines](/static/documents/foundation-visual-guidelines.pdf).
 
 <table class="logos">
   <tr>

locale/en/about/trademark.md

@@ -5,28 +5,10 @@ title: Trademark Policy
 
 # Trademark Policy
 
-The Node.js trademarks, service marks, and graphics marks are symbols of the
-quality, performance, and ease of use that people have come to associate with
-the Node.js software and project. To ensure that the Node.js marks continue to
-symbolize these qualities, we must ensure that the marks are only used in ways
-that do not mislead people or cause them to confuse Node.js with other software
-of lower quality. If we don’t ensure the marks are used in this way, it cannot
-only confuse users, it can make it impossible to use the mark to protect
-against people who maliciously exploit the mark in the future. The primary goal
-of this policy is to make sure that this doesn’t happen to the Node.js mark, so
-that the community and users of Node.js are always protected in the future.
+The Node.js trademarks, service marks, and graphics marks are symbols of the quality, performance, and ease of use that people have come to associate with the Node.js software and project. To ensure that the Node.js marks continue to symbolize these qualities, we must ensure that the marks are only used in ways that do not mislead people or cause them to confuse Node.js with other software of lower quality. If we don’t ensure the marks are used in this way, it cannot only confuse users, it can make it impossible to use the mark to protect against people who maliciously exploit the mark in the future. The primary goal of this policy is to make sure that this doesn’t happen to the Node.js mark, so that the community and users of Node.js are always protected in the future.
 
-At the same time, we’d like community members to feel comfortable spreading the
-word about Node.js and participating in the Node.js community. Keeping that
-goal in mind, we’ve tried to make the policy as flexible and easy to understand
-as legally possible.
+At the same time, we’d like community members to feel comfortable spreading the word about Node.js and participating in the Node.js community. Keeping that goal in mind, we’ve tried to make the policy as flexible and easy to understand as legally possible.
 
-The OpenJS Foundation has a perpetual license to use the
-[Node.js marks](https://ip-policy.openjsf.org).
-For more details on using the Node.js mark, please read the
-[full policy](https://trademark-policy.openjsf.org).
-If you have any questions don't hesitate to
-[email us](mailto:trademark@openjsf.org).
+The OpenJS Foundation has a perpetual license to use the [Node.js marks](https://ip-policy.openjsf.org). For more details on using the Node.js mark, please read the [full policy](https://trademark-policy.openjsf.org). If you have any questions don't hesitate to [email us](mailto:trademark@openjsf.org).
 
-Guidelines for the visual display of the Node.js mark are described in
-the [Visual Guidelines](/static/documents/foundation-visual-guidelines.pdf).
+Guidelines for the visual display of the Node.js mark are described in the [Visual Guidelines](/static/documents/foundation-visual-guidelines.pdf).