修正中

core/about/release-cycle/block-editor-release-process-for-major-releases.md

@@ -264,13 +264,13 @@ For items in the “To Do” column, it’s recommended that you find someone as
 **Review [release roadmap post](https://make.wordpress.org/core/2023/05/18/roadmap-to-6-3/) and recent** [**“What’s New”**](https://make.wordpress.org/core/tag/gutenberg-new/) **release posts to determine important features**
 -->
 
-**[リリースロードマップの投稿](https://make.wordpress.org/core/2023/05/18/roadmap-to-6-3/)と最近の** [**"What's New"**](https://make.wordpress.org/core/tag/gutenberg-new/) **リリース投稿をレビューし、重要な機能を決定します**。
+**[リリースロードマップの投稿](https://make.wordpress.org/core/2023/05/18/roadmap-to-6-3/)と最近の** [**「What's New」**](https://make.wordpress.org/core/tag/gutenberg-new/) **リリース投稿をレビューし、重要な機能を決定します**。
 
 <!--
 The release roadmap post lists the features considered top priority for each release. Special attention should be given to these to make sure they land in core in a timely and stable manner.
 -->
 
-リリースロードマップの投稿には、各リリースで最優先とされる機能がリストアップされている。タイムリーで安定した方法でコアに取り込まれるよう、これらに特別な注意を払う必要があります。
+リリースロードマップの投稿には、各リリースで最優先とされる機能がリストアップされています。タイムリーで安定した方法でコアに取り込まれるよう、これらに特別な注意を払う必要があります。
 
 <!--
 To get a sense of all the features currently being worked on, as well as smaller enhancements and bug fixes, it’s good to review plugin release posts too.
@@ -430,7 +430,7 @@ With the information from the report and any information manually collected, it
 In order to know what needs a Dev Note, you can check all PRs [labeled with  “Needs Dev Note”.](https://github.com/WordPress/gutenberg/issues?q=label%3A%22Needs+Dev+Note%22.) You might find that there are more PRs than you can feasible write individual posts for without overwhelming the community with information. The best thing to do if you find too many PRs with that label is to group related changes and propose a dev note for each group.
 -->
 
-Dev Note が必要なものを知るために、[「Needs Dev Note」とラベルづけされた](https://github.com/WordPress/gutenberg/issues?q=label%3A%22Needs+Dev+Note%22.)プルリクエストをすべてチェックできます。コミュニティを情報で圧倒することがないように個々の投稿を書くことが不可能なほど、多くのプルリクエストがあることに気付くかもしれません。このようなラベルのプルリクエストが多すぎる場合、最善の方法は、関連する変更をグループ化しグループごとに開発ノートを提案することです。
+Dev Note が必要なものを知るために、[「Needs Dev Note」とラベルづけされた](https://github.com/WordPress/gutenberg/issues?q=label%3A%22Needs+Dev+Note%22.)プルリクエストをすべてチェックできます。個々の投稿を書くことでコミュニティを情報で圧倒してしまうほど、多くのプルリクエストがあることに気付くかもしれません。このようなラベルのプルリクエストが多すぎる場合、最善の方法は、関連する変更をグループ化しグループごとに開発ノートを提案することです。
 
 <!--
 Once you have a sense of the different dev notes that are needed, create a GitHub issue ([previous example](https://github.com/WordPress/gutenberg/issues/20185)) detailing the plan: what posts need to be done, what sections for each post, and which PRs are included in each. When doing so, make sure to ping the people that had PRs needing dev notes to contribute to this effort. Your job ideally should be to wrangle the updates from each PR author and plan out the timeline for sharing each dev note so that you don’t share too many in a short period of time. To help with this, it’s recommended to share target dates in order to help space out and plan appropriately. 
@@ -466,7 +466,7 @@ As you compile each dev note, particularly if you are combining multiple PRs int
 Because months pass between core releases, it’s important to regularly check in on GitHub to triage issues (ideally weekly) particularly [new ones that are unlabeled](https://github.com/WordPress/gutenberg/issues?q=is%3Aissue+is%3Aopen+no%3Alabel+sort%3Acreated-desc). The key is to not miss anything that might be critical. 
 -->
 
-コアリリースの間に数ヵ月が経過するため、GitHub で定期的に (理想的には毎週) 問題をトリアージすることが重要です。特に、[ラベルのない新しい issue](https://github.com/WordPress/gutenberg/issues?q=is%3Aissue+is%3Aopen+no%3Alabel+sort%3Acreated-desc)が重要です。ポイントは、重大かもしれないものを見逃さないことです。
+コアリリースの間に数ヵ月が経過するため、GitHub で定期的に (理想的には毎週) 問題をトリアージすることが重要です。特に、[ラベルのない新しい issue](https://github.com/WordPress/gutenberg/issues?q=is%3Aissue+is%3Aopen+no%3Alabel+sort%3Acreated-desc) が重要です。ポイントは、重大かもしれないものを見逃さないことです。
 
 <!--
 **High Level Triage**
@@ -544,7 +544,7 @@ In order to safely update the npm packages in core, experimental Gutenberg featu
 Create an overview issue of all the changes from the `lib` and `phpunit` folders that need to be manually synced. Using git blame, find the authors of those changes and ping them to create core PRs for them.
 -->
 
-手動で同期する必要がある `lib` フォルダーと `phpunit` フォルダーから、すべての変更に関する概要の issue を作成します。 gitblame を使用して、それらの変更の作成者を見つけて通知し、それらの変更のコアプルリクエストを作成します。
+手動で同期する必要がある `lib` フォルダーと `phpunit` フォルダーから、すべての変更に関する概要の issue を作成します。 git blame を使用して、それらの変更の作成者を見つけて通知し、それらの変更のコアプルリクエストを作成します。
 
 <!--
 The PHP files in `block-library` package don’t need to be manually synced, as they are auto-generated in core based on the npm package.
@@ -562,7 +562,7 @@ The PHP files in `block-library` package don’t need to be manually synced, as
 After the first beta, there are weekly beta releases leading up to the Release Candidate. At this point, there are three main tasks to take care of: triage new issues, cherry-pick PRs for inclusion in the release, and update package and core paths. The following section is broken down into these three areas. 
 -->
 
-最初のベータ版の後、リリース候補に至るまで毎週ベータ版がリリースされます。この時点では、新しい問題のトリアージ、リリースに含めるプルリクエストのチェリーピック、パッケージとコアパスの更新という3つの主なタスクがあります。次のセクションでは、これら3つの領域に分けて説明します。
+最初のベータ版の後、リリース候補に至るまで毎週ベータ版がリリースされます。この時点では、新しい issue のトリアージ、リリースに含めるプルリクエストのチェリーピック、パッケージとコアパスの更新という3つの主なタスクがあります。次のセクションでは、これら3つの領域に分けて説明します。
 
 <!--
 **Triage New Issues**
@@ -588,7 +588,7 @@ Outside of triaging these issues for inclusion in the “Must Haves” project b
 
 「Must Haves」プロジェクトボードに含めるためにこれらの issue をトリアージする以外には、特にベータ版のリリースが毎週のスケジュールで行われるため、追加された issue が誰かに割り当てられ、解決されるようにすることが重要です。
 
-### リリース用 PR のチェリーピックについて
+### リリース用プルリクエストのチェリーピックについて
 
 <!--
 Once tasks on the “Must Haves” board are completed they need to be backported into the core to be available on the next beta or RC version. This is the process to do it: