fix(ja): replace 承認 with 認可 for authorization contexts#23178
Conversation
- RBAC: 承認テーブル/承認関係 → 認可テーブル/認可関係 - OAuth: 承認されたOAuthアプリ → 認可されたOAuthアプリ - SSO: 偽装の承認/承認して保存 → 偽装の認可/認可して保存 - Session: 承認コード → 認可コード - Network: 承認(済み)ネットワーク → 認可(済み)ネットワーク - Data access: 承認されたユーザー/ソース → 認可されたユーザー/ソース - IAM: 権限を承認する → 権限を認可する - Encryption: 承認されたアカウント/承認 → 認可されたアカウント/認可
|
Skipping CI for Draft Pull Request. |
ti-chi-bot
Bot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ti-chi-bot
Bot
added
missing-translation-status
|
Scope too broad; will reopen with only authentication-and-authorization paired contexts |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request standardizes the Japanese translation of "authorization" to "認可" (previously "承認") across several documentation files, and simplifies a note about Perl dependencies. The review feedback is highly constructive, pointing out a few instances of incomplete replacements, suggesting the more natural phrasing "権限を付与する" for granting privileges, and maintaining consistency with "認証コード" in the session sharing documentation.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| > **注記：** | ||
| > | ||
| > - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を承認することを前提としています。IAM ロールを使用して権限を承認する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 | ||
| > - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を認可することを前提としています。IAM ロールを使用して権限を認可する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 |
There was a problem hiding this comment.
In Japanese IT documentation, "granting/authorizing privileges" is standardly translated as "権限を付与する" rather than "権限を認可する". "権限を認可する" sounds unnatural in Japanese because "権限" means privileges/authority, and "認可" means authorization. "権限を付与する" is already consistently used throughout other files in this repository (e.g., role-based-access-control.md).
| > - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を認可することを前提としています。IAM ロールを使用して権限を認可する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 | |
| > - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を付与することを前提としています。IAM ロールを使用して権限を付与する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 |
References
- Use consistent terminology. (link)
|  | ||
|
|
||
| 2. **承認コード**をクリックしてサインインに使用します。 | ||
| 2. **認可コード**をクリックしてサインインに使用します。 |
There was a problem hiding this comment.
In this file, the term "sharing code" is translated as "認証コード" in other places (e.g., step 3: "招待者から受け取った認証コードを入力します", step 5: "[認証コードの生成]をクリックします", step 6: "生成された認証コードを..."). Changing "承認コード" to "認可コード" in step 2 introduces a terminology inconsistency, as "認可コード" (authorization code) is a standard OAuth 2.0 term and is different from "認証コード" (sharing code) used elsewhere in the same session sharing context. It should be changed to "認証コード" to be consistent.
| 2. **認可コード**をクリックしてサインインに使用します。 | |
| 2. **認証コード**をクリックしてサインインに使用します。 |
References
- Use consistent terminology. (link)
| ``` | ||
|
|
||
| この操作により、 `mysql.user`テーブル内の`app_read`と`app_write`ロール レコードと、承認テーブル内の関連レコードが削除され、2 つのロールに関連する承認が終了します。 | ||
| この操作により、 `mysql.user`テーブル内の`app_read`と`app_write`ロール レコードと、認可テーブル内の関連レコードが削除され、2 つのロールに関連する承認が終了します。 |
There was a problem hiding this comment.
The replacement of "承認" with "認可" is incomplete in this sentence. The word "承認" at the end of the sentence ("2 つのロールに関連する承認が終了します") should also be replaced with "認可" to be consistent with the rest of the sentence and the PR's objective.
| この操作により、 `mysql.user`テーブル内の`app_read`と`app_write`ロール レコードと、認可テーブル内の関連レコードが削除され、2 つのロールに関連する承認が終了します。 | |
| この操作により、 `mysql.user`テーブル内の`app_read`と`app_write`ロール レコードと、認可テーブル内の関連レコードが削除され、2 つのロールに関連する認可が終了します。 |
References
- Use consistent terminology. (link)
| 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、<mdsvgicon name="icon-top-account-settings">左下隅にあります。</mdsvgicon> | ||
| 2. **[アカウント設定]**をクリックします。 | ||
| 3. **「承認済みOAuthアプリ」**タブをクリックします。承認済みのOAuthアプリケーションが表示されます。 | ||
| 3. **「認可済みOAuthアプリ」**タブをクリックします。承認済みのOAuthアプリケーションが表示されます。 |
There was a problem hiding this comment.
The replacement of "承認" with "認可" is incomplete in this sentence. The word "承認済み" in "承認済みのOAuthアプリケーションが表示されます" should also be replaced with "認可済み" to be consistent with the tab name and the PR's objective.
| 3. **「認可済みOAuthアプリ」**タブをクリックします。承認済みのOAuthアプリケーションが表示されます。 | |
| 3. **「認可済みOAuthアプリ」**タブをクリックします。認可済みのOAuthアプリケーションが表示されます。 |
References
- Use consistent terminology. (link)
1 participant
What is changed, added or deleted? (Required)
Replace Japanese
承認(approval) with認可(authorization) in IT/security contexts across 19 files.In Japanese IT documentation, "authorization" should be translated as
認可, not承認. The word承認means "approval" (e.g., manager approval, budget sign-off) and is incorrect for technical authorization contexts.Changes
承認テーブル→認可テーブル,承認関係→認可関係承認されたOAuthアプリ→認可されたOAuthアプリ偽装の承認→偽装の認可,承認して保存→認可して保存承認コード→認可コード承認(済み)ネットワーク→認可(済み)ネットワーク承認されたユーザー/ソース→認可されたユーザー/ソース権限を承認する→権限を認可する承認されたTiDB Cloudアカウント→認可されたTiDB CloudアカウントWhich TiDB version(s) do your changes apply to? (Required)
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?