diff --git a/locale/en/blog/npm/2013-outage-postmortem.md b/locale/en/blog/npm/2013-outage-postmortem.md
index afe9dda9ea85c..01c2cb5238d4c 100644
--- a/locale/en/blog/npm/2013-outage-postmortem.md
+++ b/locale/en/blog/npm/2013-outage-postmortem.md
@@ -28,10 +28,10 @@ There are two distinct components that make up npmjs.org operated by different p
Here is a high-level summary of the _old architecture:_
-
-
- _Diagram 1. Old npm architecture_
-
+
+
+ Diagram 1. Old npm architecture
+
## What went wrong and how was it fixed?
@@ -44,10 +44,10 @@ The incident on November 4th was ultimately resolved by a reboot and resize of t
When neither of these yielded a solution Jason Smith and I decided to move to a multi-master architecture with continuous replication illustrated below:
-
-
+
+
+ Diagram 2. Current npm architecture -- Red-lines denote continuous replication
+
This _should_ have been the end of our story but unfortunately our supervision logic did not function properly to restart the secondary master on the morning of November 15th. During this time we [moved briefly][ops-single-server] back to a single master architecture. Since then the secondary master has been closely monitored by the entire Nodejitsu operations team to ensure it's continued stability.
@@ -62,10 +62,11 @@ The public npm registry simply cannot go down. **Ever.** We gained a lot of oper
When these new infrastructure components are in-place The npm Registry will look like this:
-
-
NAME
+
+```
+NAME
npm-shrinkwrap -- Lock down dependency versions
SYNOPSIS
npm shrinkwrap
DESCRIPTION
- This command locks down the versions of a package's dependencies so
+ This command locks down the versions of a package's dependencies so
that you can control exactly which versions of each dependency will
- be used when your package is installed.
+ be used when your package is installed.
+```
+
Let's consider package A:
diff --git a/locale/en/docs/guides/simple-profiling.md b/locale/en/docs/guides/simple-profiling.md
index 5bf106b2204ce..d343242a5a757 100644
--- a/locale/en/docs/guides/simple-profiling.md
+++ b/locale/en/docs/guides/simple-profiling.md
@@ -196,15 +196,15 @@ Parsing this section takes a little more work than the raw tick counts above.
Within each of the "call stacks" above, the percentage in the parent column
tells you the percentage of samples for which the function in the row above was
called by the function in the current row. For example, in the middle "call
-stack" above for _sha1_block_data_order, we see that _sha1_block_data_order occurred
+stack" above for _sha1_block_data_order, we see that `_sha1_block_data_order` occurred
in 11.9% of samples, which we knew from the raw counts above. However, here, we
can also tell that it was always called by the pbkdf2 function inside the
-Node.js crypto module. We see that similarly, _malloc_zone_malloc was called
+Node.js crypto module. We see that similarly, `_malloc_zone_malloc` was called
almost exclusively by the same pbkdf2 function. Thus, using the information in
this view, we can tell that our hash computation from the user's password
accounts not only for the 51.8% from above but also for all CPU time in the top
-3 most sampled functions since the calls to _sha1_block_data_order and
-_malloc_zone_malloc were made on behalf of the pbkdf2 function.
+3 most sampled functions since the calls to `_sha1_block_data_order` and
+`_malloc_zone_malloc` were made on behalf of the pbkdf2 function.
At this point, it is very clear that the password based hash generation should
be the target of our optimization. Thankfully, you've fully internalized the
diff --git a/locale/ko/about/resources.md b/locale/ko/about/resources.md
index cd3f1b600896c..8a14cc5e5a798 100644
--- a/locale/ko/about/resources.md
+++ b/locale/ko/about/resources.md
@@ -8,58 +8,58 @@ title: 로고와 그래픽
## Logo Downloads
- Please review the [trademark policy](/about/trademark/) for information about permissible use of Node.js® logos and marks.
+ Please review the trademark policy> 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).
+ the Visual Guidelines>.
-->
# 관련 자료
## 로고 다운로드
-Node.js® 로고와 마크를 사용할 수 있는 경우에 대한 정보는 [상표 정책](/about/trademark/)을
+Node.js® 로고와 마크를 사용할 수 있는 경우에 대한 정보는 상표 정책>을
확인해보기 바랍니다.
Node.js의 시각적인 가이드라인은
-[시각적 가이드라인](/static/documents/foundation-visual-guidelines.pdf)에 나와 있습니다.
+시각적 가이드라인>에 나와 있습니다.
diff --git a/locale/ko/docs/guides/simple-profiling.md b/locale/ko/docs/guides/simple-profiling.md
index d432c321026ef..ea3afbd35cc7c 100644
--- a/locale/ko/docs/guides/simple-profiling.md
+++ b/locale/ko/docs/guides/simple-profiling.md
@@ -391,15 +391,15 @@ Parsing this section takes a little more work than the raw tick counts above.
Within each of the "call stacks" above, the percentage in the parent column
tells you the percentage of samples for which the function in the row above was
called by the function in the current row. For example, in the middle "call
-stack" above for _sha1_block_data_order, we see that _sha1_block_data_order occurred
+stack" above for _sha1_block_data_order, we see that `_sha1_block_data_order` occurred
in 11.9% of samples, which we knew from the raw counts above. However, here, we
can also tell that it was always called by the pbkdf2 function inside the
-Node.js crypto module. We see that similarly, _malloc_zone_malloc was called
+Node.js crypto module. We see that similarly, `_malloc_zone_malloc` was called
almost exclusively by the same pbkdf2 function. Thus, using the information in
this view, we can tell that our hash computation from the user's password
accounts not only for the 51.8% from above but also for all CPU time in the top
-3 most sampled functions since the calls to _sha1_block_data_order and
-_malloc_zone_malloc were made on behalf of the pbkdf2 function.
+3 most sampled functions since the calls to `_sha1_block_data_order` and
+`_malloc_zone_malloc` were made on behalf of the pbkdf2 function.
At this point, it is very clear that the password based hash generation should
be the target of our optimization. Thankfully, you've fully internalized the
diff --git a/locale/uk/about/resources.md b/locale/uk/about/resources.md
index d3b72fdd9e825..f4157ab4d1157 100644
--- a/locale/uk/about/resources.md
+++ b/locale/uk/about/resources.md
@@ -13,19 +13,19 @@ title: Лого та графіка
-
[](/static/images/logos/nodejs-new-pantone-black.ai)
-
[](/static/images/logos/nodejs-new-pantone-white.ai)
diff --git a/locale/uk/docs/guides/simple-profiling.md b/locale/uk/docs/guides/simple-profiling.md
index 5bf106b2204ce..d343242a5a757 100644
--- a/locale/uk/docs/guides/simple-profiling.md
+++ b/locale/uk/docs/guides/simple-profiling.md
@@ -196,15 +196,15 @@ Parsing this section takes a little more work than the raw tick counts above.
Within each of the "call stacks" above, the percentage in the parent column
tells you the percentage of samples for which the function in the row above was
called by the function in the current row. For example, in the middle "call
-stack" above for _sha1_block_data_order, we see that _sha1_block_data_order occurred
+stack" above for _sha1_block_data_order, we see that `_sha1_block_data_order` occurred
in 11.9% of samples, which we knew from the raw counts above. However, here, we
can also tell that it was always called by the pbkdf2 function inside the
-Node.js crypto module. We see that similarly, _malloc_zone_malloc was called
+Node.js crypto module. We see that similarly, `_malloc_zone_malloc` was called
almost exclusively by the same pbkdf2 function. Thus, using the information in
this view, we can tell that our hash computation from the user's password
accounts not only for the 51.8% from above but also for all CPU time in the top
-3 most sampled functions since the calls to _sha1_block_data_order and
-_malloc_zone_malloc were made on behalf of the pbkdf2 function.
+3 most sampled functions since the calls to `_sha1_block_data_order` and
+`_malloc_zone_malloc` were made on behalf of the pbkdf2 function.
At this point, it is very clear that the password based hash generation should
be the target of our optimization. Thankfully, you've fully internalized the
diff --git a/locale/zh-cn/about/resources.md b/locale/zh-cn/about/resources.md
index 6dcffb4d3ecef..4c2b473d4d49b 100644
--- a/locale/zh-cn/about/resources.md
+++ b/locale/zh-cn/about/resources.md
@@ -12,19 +12,19 @@ title: 商标和图像
-
-
-