Update

core/about/release-cycle/releasing-minor-versions.md

@@ -10,7 +10,11 @@ So, you wanna ship a minor version of WordPress? Okay, maybe you don’t *want*
 
 WordPress のマイナーバージョンをリリースしたいですか ? おそらくそう**したくない**かもしれませんし、WordPress のマイナーバージョンをリリースする**必要がある**かもしれません。マイナーリリースは、新しくデプロイされるファイルを追加しないバグ修正や機能拡張を目的としており、コンポーネントのメンテナーやコミッターからの提案やアドバイスを受け、リリースリードの裁量によって決定されます。以下に記載されているように、これらのリリースには多くのことが関係します。以前にリリースプロセスを実行したことがあり、何か不足しているものがある場合は**追加してください**。
 
+<!--
 ## Before Release
+-->
+
+## リリースの前に
 
 <!--
 Before you’ve decided to release, there are a few things to consider \[TODO: Add more to this section\]:
@@ -192,13 +196,13 @@ You’ve made it. Release day can be stressful. The best way to survive release
 -->
 
 *   新しい貢献者をリストアップするために、関連するクレジットファイルを更新する必要があります。このファイルは [meta リポジトリ](https://meta.trac.wordpress.org/browser/sites/trunk/api.wordpress.org/public_html/core/credits) にあります。
-*   セキュリティリリースを実行する場合、セキュリティパッチをすべての関連ブランチに コミットする必要があります。
-*   セキュリティパッチがコミットされたら、リリースプロセスを [#core](https://make.wordpress.org/core/tag/core/) チャネルに移動してください。
-    *   (`/here` Slack コマンドを使用して) リリースパーティーへの参加を歓迎するアナウンス を行うことから始めます。
+*   セキュリティリリースを実行する場合、セキュリティパッチをすべての関連ブランチにコミットする必要があります。
+*   セキュリティパッチがコミットされたら、リリースプロセスを [#core](https://make.wordpress.org/core/tag/core/) チャンネルに移動してください。
+    *   (`/here` Slack コマンドを使用して) リリースパーティーへの参加を歓迎するアナウンスを行うことから始めます。
     *   コミッターに対して、リリースが完了するまでコミットを控えるようリクエストを投稿します。例: `@committers please refrain from committing during the release process`。
 *   バージョンアップは関連するすべてのブランチでコミットする必要があります。[これがその例です](https://core.trac.wordpress.org/changeset/44078)。コアコミッターであれば誰でもこのステップを実行できます。最新のブランチでバージョンアップをコミットする際には、version.php と about.php の両方を更新してください。package.json ファイルは現在のブランチですでに更新されているはずですが、それ以前のブランチでは更新する必要があります ([例](https://core.trac.wordpress.org/changeset/39862))。
     *   `package.json` には `X.Y.Z` への単純なバージョンアップが1つあります。
-    *   `version.php` には `X.Y.Z-src` にバージョンアップが一つあります。接尾辞の `-src` は、develop.svn にコミットする際に常に含める必要があることに注意してください。
+    *   `version.php` には `X.Y.Z-src` へのバージョンアップが一つあります。接尾辞の `-src` は、develop.svn にコミットする際に常に含める必要があることに注意してください。
     * `about.php` の見出しである「Maintenance and Security Release(s)」に `Z` という数字を追加し、下部にある既存の文字列を使用して、リリースの変更点を説明する段落を追加する必要があります。これらの文字列はブランチによって異なりますので、必ず正しいバージョンのものを使用してください。他の場所から適切な段落をコピー & ペーストすることが一番簡単です。これがブランチの最初のマイナーリリースである場合、ナビゲ―ションタブの後に追加するラッパー div と前述の `h3` もあります。単一または複数のセキュリティやバグの修正について、考えられる文字列の組み合わせをメモしておきます。違いについては、[より完全な説明](#selecting-strings)をチェックしてください。
     *   これらの変更を事前に十分に準備し、レビューを依頼しましょう。そうすることで、リリースプロセスの停滞を避けることができます。バージョンアップとアバウトページは一緒にコミットでき、別々に行う必要はありません。
 *   すべてのブランチで、リリースには[タグが必要です](https://build.trac.wordpress.org/browser/tags/)。多くの人は SVN からリリースを実行し、そのためにタグに依存しています。タグ付けは以下のコマンドで完了します (関連ブランチとリリースで必ず更新してください): `svn cp https://develop.svn.wordpress.org/branches/5.7 https://develop.svn.wordpress.org/tags/5.7.2 -m "Tag 5.7.2"` `https://develop.svn.wordpress.org` がチェックアウトするリポジトリのルートであることを二重三重にチェックした場合は、`^` ショートカットを使用できます: `svn cp ^/branches/5.7 ^/tags/5.7.2 -m "Tag 5.7.2"`.
@@ -212,11 +216,11 @@ You’ve made it. Release day can be stressful. The best way to survive release
 *   リリースの言語パックは、`translate/bin/update-all-core-packs.sh` のバージョンを上げてビルドし、デプロイする必要があります。(このファイルは dotorg サンドボックスへのアクセスを必要とします)。
 *   wordpress.org/news/ の投稿を公開する必要があります。
 *   この時点でリリースパーティは完了し、管理タスクのみが残ります。
-    *   リリース中にテストに協力してくれた参加者に感謝すします。
+    *   リリース中にテストに協力してくれた参加者に感謝します。
     *   コミッターにコミットができるようになったことを伝えます: `@committers feel free to commit as usual, thank you for your patience during the release`
 *   リリースしたことを make/polyglots に知らせます。ロケールによっては、自動ビルドに頼らず独自のビルドを行い、独自にパッケージ化する必要があります。[これがその例です](https://make.wordpress.org/polyglots/2021/04/15/35197/)。
 *   すべての HelpHub バージョンページを更新します:
-    *   [マイナーリリース版ページ](https://wordpress.org/support/wordpress-version/version-5-7-1/)に[ファイルの差分リスト](https://codex.wordpress.org/Template:Release)とニュース記事へのリンクを追加する。
+    *   [マイナーリリース版ページ](https://wordpress.org/support/wordpress-version/version-5-7-1/)に[ファイルの差分リスト](https://codex.wordpress.org/Template:Release)とニュース記事へのリンクを追加します。
     *   [WordPress Versions](https://wordpress.org/support/article/wordpress-versions/) にバージョン情報とバージョンページへのリンクを追加します。
 *   Codex の [CurrentVersion テンプレート](https://codex.wordpress.org/Template:CurrentVersion)を新しいバージョンに更新します。
 *   Codex [WordPress Versions](https://codex.wordpress.org/WordPress_Versions) ページに新しいバージョンを追加します。
@@ -326,10 +330,12 @@ There are a few ways to test package builds, but using WP-CLI is a fast, effecti
 
 パッケージのビルドをテストする方法はいくつかありますが、WP-CLI を使用することが早く効果的な方法です。ここでは、バージョン間のアップグレードをテストするために使用できるコマンドを紹介します。この例では、4.5.2と4.5.3の間をテストし、WordPress バージョン3.7以上がすでにインストールされていると仮定します。
 
+<!--
 *   `$ wp core download --version=4.5.2 --force` This will retrieve the version you want to start from.
 *   `$ wp core update-db` Get the database where it needs to be.
 *   `$ wp core update https://wordpress.org/wordpress-4.5.3.zip` Update to the package you’re testing.
 *   `$ wp core update-db` Make sure any database updates run.
+-->
 
 *   `$ wp core download --version=4.5.2 --force` 開始したいバージョンを取得します。
 *   `$ wp core update-db` 必要なデータベースを取得します。