diff --git a/core/about/release-cycle/hosting-release-parties.md b/core/about/release-cycle/hosting-release-parties.md
index 741cb4d..ff5a684 100644
--- a/core/about/release-cycle/hosting-release-parties.md
+++ b/core/about/release-cycle/hosting-release-parties.md
@@ -156,7 +156,7 @@ Thanks, everyone, for joining in and helping make WordPress! Hope to see you at
 | **ステップ6:** バージョンアップ | @corecommitter, will you please commit the first version bump?<br /><br />**\[コミットされるのを待つ\]** | コアコミッター |
 | **ステップ7:** パッケージをビルドする | @mcpilot please proceed to package the release and post the link to the package here. | コアコミッター |
 | **ステップ8:** パッケージに関するお知らせ | \[**パッケージがビルドされている間は、テストが終わってリリースの投稿が公開されるまで、パッケージへのリンクを公の場に共有しないよう、もう一度参加者に注意してください。パッケージング中にエラーが起こり、パッケージの再構築が必要になることがあります。**\]<br /><br />:siren: Please remember not to share links to the package publicly until the “all clear” is given after testing and the announcement post is published on WordPress.org. :siren:<br /><br />**\[.zip ファイルへのリンクが貼られるまで待つ。\]** | ホスト |
-| **ステップ8:** テスト | I**t’s testing time**!<br /><br />There are several ways to test, so pick whatever feels most comfortable and report back as you go:<br /><br />1\. Install and activate the [WordPress Beta Tester](https://wordpress.org/plugins/wordpress-beta-tester/) plugin. Select the Bleeding edge channel and then Beta/RC Only stream.<br />2\. Use WP-CLI to test: wp core update –version=`X.Y-Z`<br />3\. Directly download the Beta/RC version from https://wordpress.org/wordpress-`X.Y-Z`.zip<br /><br />**Here are a few scenarios to test:**<br />– Test from latest in 4.0.\* release series (e.g., 4.0.35 > `X.Y-Z`)<br />– Test from latest in 4.9.\* release series (e.g., 4.9.21 > `X.Y-Z`)<br />– Test from the latest version in the current major release series (e.g., 6.1.1 > `X.Y-Z`) – Test from the most recent Beta/RC release (e.g., Beta 4 > `X.Y-Z`) – Test fresh installation<br />– Remove `wp-config.php` file and test a fresh installation<br />– Test single site and multisite/network (both subdirectory and subdomain) installations<br /><br />You can report back by sharing how you tested and what the result was with an emoji. For example:<br />– 6.2-beta1 > `X.Y-Z` via beta tester<br />If it works, add :white\_check\_mark:<br />If any issues happen, add :red\_circle: so we can investigate. | 全員 |
+| **ステップ8:** テスト | I**t’s testing time**!<br /><br />There are several ways to test, so pick whatever feels most comfortable and report back as you go:<br /><br />1\. Install and activate the [WordPress Beta Tester](https://wordpress.org/plugins/wordpress-beta-tester/) plugin. Select the Bleeding edge channel and then Beta/RC Only stream.<br />2\. Use WP-CLI to test: wp core update –version=`X.Y-Z`<br />3\. Directly download the Beta/RC version from https://wordpress.org/wordpress-`X.Y-Z`.zip<br /><br />**Here are a few scenarios to test:**<br />– Test from latest in 4.0.\* release series (e.g., 4.0.35 > `X.Y-Z`)<br />– Test from latest in 4.9.\* release series (e.g., 4.9.21 > `X.Y-Z`)<br />– Test from the latest version in the current major release series (e.g., 6.1.1 > `X.Y-Z`) – Test from the most recent Beta/RC release (e.g., Beta 4 > `X.Y-Z`) – Test fresh installation<br />– Remove `wp-config.php` file and test a fresh installation<br />– Test single site and multisite/network (both subdirectory and subdomain) installations<br /><br />You can report back by sharing how you tested and what the result was with an emoji. For example:<br />– 6.2-beta1 > `X.Y-Z` via beta tester<br />If it works, add :white\_check\_mark:<br />If any issues happen, add :red\_circle: so we can investigate. <br /><br />Please note that language packs are built in a later step of the process, so it is normal for there to be notices such as `**注意: チェックサムは WordPress 6.3.2/fr_FR では利用できません。 ファイルを手動でクリーンアップしてください。**`| 全員 |
 | **Optional**: 見つかった問題点をまとめる | **\[テスト中に問題が見つかった場合は、このセクションを参照してください。\]**<br />Thanks, everyone, for testing! For now, we’re tracking the following issues: | ホスト |
 | **ステップ9:** 2番目のバージョンアップ | Please, @corecommitter, proceed with the second version bump.<br /><br />**\[コミットされるのを待つ\]** | コアコミッター |
 | **ステップ10:** ミッションコントロールでナイトリーパッケージを再ビルドする | @mcpilot, can you please refresh the nightly build?<br /><br />**\[確認を待つ\]** | ミッションコントロール |
diff --git a/core/about/release-cycle/releasing-beta-versions.md b/core/about/release-cycle/releasing-beta-versions.md
index 34a80e6..41b73e0 100644
--- a/core/about/release-cycle/releasing-beta-versions.md
+++ b/core/about/release-cycle/releasing-beta-versions.md
@@ -176,7 +176,7 @@ These are the prescribed steps to take when releasing a beta version of WordPres
         *   例: [@committers](https://wordpress.slack.com/admin/user_groups) Feel free to resume committing. Reminder that we are now in the RC period so all commits will require double-signoff using the `dev-feedback` and `dev-reviewed` Trac keywords on each ticket.
 *   ベータ版のリリースプロセスでテストやその他の手伝いをしてくれた人全員に感謝し、賛辞を贈るメッセージを [#props](https://wordpress.slack.com/messages/C0FRG66LR) チャンネルに書き込みます。
     *   例: Props to @mention, @mention2, …, @mentionN for helping test today’s 5.8 Beta 1 release!
-*   For a major Beta/RC release, update the Make/Core page for the cycle with details for the release, including links to the release post, Slack Archive, and the Zip Download. Example: [https://make.wordpress.org/core/6-4/](https://make.wordpress.org/core/6-4/).
+*   ベータ/RC リリースの場合は、リリース投稿、Slack アーカイブ、Zip ダウンロードへのリンクなど、リリースの詳細を含むサイクルの Make/Core ページを更新します。例: [https://make.wordpress.org/core/6-4/](https://make.wordpress.org/core/6-4/)。
 *  リリースサイクルの最初のベータ版の場合:
     *   次のリリースバージョンの新しいマイルストーンをコア Trac に追加します。たとえば、WordPress `5.0` をリリースするときに、`5.1` のマイルストーンを追加します。**これを行うには、Trac の管理者権限を持つ人に依頼する必要があるかもしれません。**
     *   セキュリティチームのメンバーは、HackerOne プログラムの参加者にメールを送り、[安定版リリースに入る前に新しい脆弱性を見つけてください](https://make.wordpress.org/security/2019/02/13/doubling-bounties-for-vulnerabilities-discovered-before-release/)と促すべきです。詳細は、セキュリティチームハンドブックを参照してください。
diff --git a/core/about/release-cycle/releasing-major-versions.md b/core/about/release-cycle/releasing-major-versions.md
index 648fae7..9b7e7da 100644
--- a/core/about/release-cycle/releasing-major-versions.md
+++ b/core/about/release-cycle/releasing-major-versions.md
@@ -292,7 +292,7 @@ A Release Candidate version is released as the last stage of the release cycle b
 *   [RC リリースのプロセス](https://ja.wordpress.org/team/handbook/core/about/release-cycle/releasing-beta-versions/)については、別のハンドブックのページに詳しく書かれています。
 *   最初のリリース候補に続いてリリース用のブランチを作成し、次のリリースに向けて trunk の初期作業を開始できるようにします。
 *   リリースサイクルの特定の部分をより明確にし、コミュニティを準備するために、リリース候補のフェーズ ([6.0の例](https://make.wordpress.org/core/2022/05/04/wordpress-6-0-release-candidate-phase/)) と上記のさまざまなプロトコルについて Make Core でアナウンスする必要があります。
-*   At this point, two Make Core posts should be published to begin gathering nominations for folks interested and able to (1) participate in the Minor Release Squad that follows this major release cycle and to (2) participate in the Major Release Square that’s up next.
+*   この時点で、2つの Make Core 投稿を公開して、興味があり、(1) このメジャーリリースサイクルに続くマイナーリリースチームに参加できる人、および (2) 次のメジャーリリースチームに参加できる人たちの候補を集め始める必要があります。
 
 ### translate.WordPress.org
 
diff --git a/core/about/release-cycle/releasing-minor-versions.md b/core/about/release-cycle/releasing-minor-versions.md
index b9dbefe..0940db8 100644
--- a/core/about/release-cycle/releasing-minor-versions.md
+++ b/core/about/release-cycle/releasing-minor-versions.md
@@ -200,7 +200,7 @@ You’ve made it. Release day can be stressful. The best way to survive release
     *   (`/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つあります。
+    *   `package.json` には `X.Y.Z` への単純なバージョンアップが1つあります (このドキュメントで後述するリリース後のバージョンアップのため、これはおそらくすでに正しいでしょう)。
     *   `version.php` には `X.Y.Z-src` へのバージョンアップが一つあります。接尾辞の `-src` は、develop.svn にコミットする際に常に含める必要があることに注意してください。
     * `about.php` の見出しである「Maintenance and Security Release(s)」に `Z` という数字を追加し、下部にある既存の文字列を使用して、リリースの変更点を説明する段落を追加する必要があります。これらの文字列はブランチによって異なりますので、必ず正しいバージョンのものを使用してください。他の場所から適切な段落をコピー & ペーストすることが一番簡単です。これがブランチの最初のマイナーリリースである場合、ナビゲ―ションタブの後に追加するラッパー div と前述の `h3` もあります。単一または複数のセキュリティやバグの修正について、考えられる文字列の組み合わせをメモしておきます。違いについては、[より完全な説明](#%e3%82%a2%e3%83%90%e3%82%a6%e3%83%88%e3%83%9a%e3%83%bc%e3%82%b8%e3%81%ae%e6%96%87%e5%ad%97%e5%88%97%e3%82%92%e9%81%b8%e6%8a%9e%e3%81%99%e3%82%8b)をチェックしてください。
     *   これらの変更を事前に十分に準備し、レビューを依頼しましょう。そうすることで、リリースプロセスの停滞を避けることができます。バージョンアップとアバウトページは一緒にコミットでき、別々に行う必要はありません。
@@ -225,7 +225,7 @@ You’ve made it. Release day can be stressful. The best way to survive release
 *   REST API に変更があった場合は、dev hub の [REST API changelog](https://developer.wordpress.org/rest-api/changelog/) を更新してください。
 *   Trac で、`X.Y.Z+1` の[新しいマイルストーン](https://core.trac.wordpress.org/admin/ticket/milestones)を作成し、古いマイルストーンを完了としてマークしてください。これは Trac の管理者が行う必要があります。
 *   Trac で、`X.Y.Z+1` リリース (バックポートを含む最新のブランチ) の[新しいバージョン](https://core.trac.wordpress.org/admin/ticket/versions)を作成してください。`Released` 日付フィールドから日付を削除してください。これも Trac の管理者が行う必要があります。
-*   最新の安定版ブランチのバージョンを `X.Y.Z+1-alpha-$REVNUM-src` にバージョンアップし、対応する `package.json` と readme を変更します。
+*   次のリリースに備えて、最新の安定版ブランチのバージョンを `X.Y.Z+1-alpha-$REVNUM-src` に、`package.json` のバージョンを `X.Y.Z+1` にバージョンアップします。更新した後に、`npm install` を実行して `package-lock.json` ファイル ([コミット例](https://core.trac.wordpress.org/changeset/56924)) を更新する必要もあります。
 *   最新の安定版ブランチのナイトリーバージョンを再ビルドします。
 
 <!--
diff --git a/core/about/release-cycle/wordpress-release-team-and-focus-leads.md b/core/about/release-cycle/wordpress-release-team-and-focus-leads.md
index cd0882e..28b3810 100644
--- a/core/about/release-cycle/wordpress-release-team-and-focus-leads.md
+++ b/core/about/release-cycle/wordpress-release-team-and-focus-leads.md
@@ -392,7 +392,11 @@ These are tasks and responsibilities that may be documented for specific roles b
 *   コアエディターのテックリードとコミュニケーションをとり、より多くのリソースや注意が必要な箇所を把握する。
 *   リリースサイクルを通して重要な問題に優先順位をつけ、緊急性の高い問題が迅速に解決されるようにする。
 
+<!--
 This work is done in collaboration and coordination with the Core Tech leads so please refer to [Block Editor Release Process for Major Releases](https://make.wordpress.org/core/handbook/about/release-cycle/block-editor-release-process-for-major-releases/) for a more detailed and practical look.
+-->
+
+この作業は コアテックリードとの協力と調整によって行われるため、より詳細で実践的な内容については[ブロックエディター メジャーリリース時のリリースプロセス](https://make.wordpress.org/core/handbook/about/release-cycle/block-editor)を参照してください。
 
 <!--
 ### Editor Design Lead
diff --git a/core/best-practices/backporting-commits.md b/core/best-practices/backporting-commits.md
index 0ef274f..e938052 100644
--- a/core/best-practices/backporting-commits.md
+++ b/core/best-practices/backporting-commits.md
@@ -62,7 +62,7 @@ To add the merge info afterwards you can run `svn merge --record-only -c 12345 '
 The branch commit message will largely be copied from the `trunk` commit(s) with a few updates. Please see the commit message documentation, especially the sections on [Merges and Reviewed By.](https://make.wordpress.org/core/handbook/best-practices/commit-messages/#reviewed-by-and-merges)
 -->
 
-ブランチのコミットメッセージは通常 `trunk` コミットからコピーされますが、`Props` と `Fixes` の間に「Merges \[`trunk changeset ID`] to the 5.0 branch.」という新しい行が追加されます。例としては、[r43276](https://core.trac.wordpress.org/changeset/43276/)を参照してください。
+ブランチコミットメッセージの大部分は `trunk` コミットからコピーされ、いくつかの更新が加えられます。コミットメッセージのドキュメント、特に[マージとレビューする人](https://ja.wordpress.org/team/handbook/core/best-practices/commit-messages/#reviewed-by-and-merges)のセクションを参照してください。
 
 <!--
 Make sure to run the above commands from the branch root, and not from a sub directory. The reason for this is that the `svn:mergeinfo` is a SVN property on `/branches/5.9` which the SVN client sets, it’s not a server side thing.
diff --git a/core/best-practices/post-comment-guidelines.md b/core/best-practices/post-comment-guidelines.md
index c4f7197..46d7c1e 100644
--- a/core/best-practices/post-comment-guidelines.md
+++ b/core/best-practices/post-comment-guidelines.md
@@ -200,9 +200,17 @@ When writing up an idea aimed at generating feedback and assessing a potential c
 
 コア貢献者コミュニティからフィードバックを得て、変更の可能性を評価することを目的としてアイデアを書き上げる場合、書かれていることが提案であり最終決定ではないことを明確にすることが重要です。これを達成するために、提案はタイトルの最初に「提案」という単語を含み、最終決定がまだなされていないことを説明する文章を本文に含めなければなりません。
 
+<!--
 ### Comments on Posts
+-->
+
+### 投稿へのコメント
 
+<!--
 Comments on posts will automatically close after 180 days (about 6 months). If you need to keep comments open, you can use the tag `#keep-comments-open` but this should only be used with a specific timeframe in mind rather than allowing comments to stay open forever.
+-->
+
+投稿へのコメントは180日 (約6ヵ月) 後に自動的に閉じられます。コメントを開いたままにしておく必要がある場合は、`#keep-comments-open` タグを使用できますが、これはコメントを永久に開いたままにするのではなく、特定の期間を念頭に置いて使用する必要があります。
 
 <!--
 ## Comments
diff --git a/core/tutorials/leading-bug-scrubs.md b/core/tutorials/leading-bug-scrubs.md
index 758e7c6..ce96d60 100644
--- a/core/tutorials/leading-bug-scrubs.md
+++ b/core/tutorials/leading-bug-scrubs.md
@@ -218,7 +218,7 @@ Awesome! Thank you!
 You are welcome to schedule a scrub at any time. You will get the most attendees by ensuring it is announced and publicized in advance. Three ways to ensure that happen are: pinging the Core Triage lead for the current release, announcing it during the Core Dev chat open floor time, or by commenting on the Core Dev chat agenda/summary posts with your interest.
 -->
 
-現在のリリースのコアトリアージリードに通知するか、コア開発者チャットのオープンフロアにボランティアとして参加するか、コア開発者チャットの要約の投稿にコメントすることで、バグスクラブをスケジュールできます。
+バグスクラブはいつでもスケジュールできます。事前に発表し知らせることで、最も多くの参加者を得ることができます。これを確実に実現する3つの方法は、現在のリリースのコアトリアージリードに 連絡すること、コア開発者チャットのオープンフロア時間中に発表すること、またはコア開発者チャットの議題や要約の投稿に興味のある内容をコメントすることです。
 
 <!--
 Have the report or list of tickets that you want to go through in mind, and someone will make sure your scrub is scheduled in the most appropriate Slack room.