i18n(ja): remove spurious ordinal markers mistranslated from "the X <noun>"

Rebased onto the current i18n-ja-release-8.5 tip. The translation pipeline
rendered English "the `X` <noun>" (X a code span: keyword, column, stage,
phase, function, parameter) with a spurious Japanese ordinal — a "番目"/"目"
suffix (reads "the X-th <noun>") or a "第" prefix (第`Load`ステージ,
第`ALTER TABLE`). Both distort the meaning. This removes the spurious ordinals;
genuine ordinals (e.g. "the second `SELECT` statement") are kept.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: yahonda

ai/guides/vector-search.md

@@ -323,7 +323,7 @@ results = (
 
 > **Note:**
 >
-> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。`.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`番目のパラメータを変更せずに制御できます。
+> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。3 `.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`パラメータを変更せずに制御できます。
 
 > `num_candidate`値を大きくすると、一般的に再現率は向上しますが、クエリのパフォーマンスが低下する可能性があります。データセットと精度要件に応じてこの値を調整してください。
 

auto-increment.md

@@ -27,7 +27,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。
 
 ## コンセプト {#concept}
 
-`AUTO_INCREMENT`は、デフォルトの列値を自動的に入力するために使用される列属性です。`INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。
+`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。2 `INSERT`ステートメントで`AUTO_INCREMENT`列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。
 
 パフォーマンス上の理由から、各TiDBサーバーには、 `AUTO_INCREMENT`個の数値が一括で割り当てられます（デフォルトでは3万個）。つまり、 `AUTO_INCREMENT`数値は一意であることが保証されますが、 `INSERT`ステートメントに割り当てられる値は、TiDBサーバーごとに単調なものになります。
 
@@ -100,7 +100,7 @@ CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int);
 INSERT INTO t (c) VALUES (1)
 ```
 
-インスタンス`A` `[1,30000]`のAUTO_INCREMENT ID をキャッシュし、インスタンス`B` `[30001,60000]`のAUTO_INCREMENT ID をキャッシュしている可能性があります。実行される`INSERT`ステートメントでは、各インスタンスのキャッシュされた ID が`AUTO_INCREMENT`番目の列にデフォルト値として割り当てられます。
+インスタンス`A` `[1,30000]`のAUTO_INCREMENT ID をキャッシュし、インスタンス`B` `[30001,60000]`のAUTO_INCREMENT ID をキャッシュしている可能性があります。実行される`INSERT`ステートメントでは、各インスタンスのキャッシュされた ID が`AUTO_INCREMENT`列にデフォルト値として割り当てられます。
 
 ## 基本機能 {#basic-features}
 
@@ -183,7 +183,7 @@ Records: 2  Duplicates: 1  Warnings: 0
 
 ## 自動IDキャッシュ {#auto-id-cache}
 
-異なるTiDBサーバーに対して`INSERT`操作を実行すると、 `AUTO_INCREMENT`番目のシーケンスが大幅に*ジャンプする*ように見える場合があります。これは、各サーバーが`AUTO_INCREMENT`の値のキャッシュを独自に持っているためです。
+異なるTiDBサーバーに対して`INSERT`操作を実行すると、 `AUTO_INCREMENT`シーケンスが大幅に*ジャンプする*ように見える場合があります。これは、各サーバーが`AUTO_INCREMENT`の値のキャッシュを独自に持っているためです。
 
 ```sql
 CREATE TABLE t (a int PRIMARY KEY AUTO_INCREMENT, b timestamp NOT NULL DEFAULT NOW());
@@ -467,6 +467,6 @@ IDは常に増加し、 `AUTO_ID_CACHE 0`のような大きなギャップは発
 -   `INTEGER` 、 `FLOAT` 、または`DOUBLE`タイプの列に定義する必要があります。
 -   `DEFAULT`列の値と同じ列には指定できません。
 -   `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`を使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`を使用することも含まれます。
--   `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`を使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用して`AUTO_INCREMENT`番目の属性を削除することはできません。
+-   `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`を使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用して`AUTO_INCREMENT`属性を削除することはできません。
 -   `ALTER TABLE` 、 `AUTO_INCREMENT`値を小さい値に設定するには`FORCE`オプションが必要です。
 -   `AUTO_INCREMENT` `MAX(<auto_increment_column>)`より小さい値に設定すると、既存の値がスキップされないため、キーが重複することになります。

best-practices/ddl-introduction.md

@@ -136,7 +136,7 @@ TiDB v6.2.0 より前では、DDL 実行フレームワークには次の制限
 
 -   [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) : この変数は、バックフィルの同時実行を制御する DDL 操作の再編成ワーカーの数を設定します。
 
--   [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) : この変数は、第`re-organize`フェーズの DDL 操作のバッチ サイズを設定し、バックフィルされるデータの量を制御します。
+-   [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) : この変数は、`re-organize`フェーズの DDL 操作のバッチ サイズを設定し、バックフィルされるデータの量を制御します。
 
     推奨値:
 
@@ -161,7 +161,7 @@ TiDB v6.2.0以降、単一の`ALTER`文でテーブル内の複数のスキー
 
 ### 読み取りと書き込みのパフォーマンスを確認する {#check-the-read-and-write-performance}
 
-TiDBがインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。`ADD INDEX`のコマンドが送信され、 `write reorg`番目のフェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。
+TiDBがインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。1 `ADD INDEX`のコマンドが送信され、 `write reorg`フェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。
 
 ## DDL関連コマンド {#ddl-related-commands}
 

br/br-pitr-guide.md

@@ -52,7 +52,7 @@ tiup br log status --task-name=pitr --pd "${PD_IP}:2379"
 -   `start` : ログ バックアップ タスクの開始タイムスタンプ。
 -   `end` : ログバックアップタスクの終了タイムスタンプ。現在、このフィールドは無効です。
 -   `storage` : ログ バックアップの外部ストレージの URI。
--   `speed(est.)` : ログバックアップの現在のデータ転送速度。この値は、過去数秒間に取得されたトラフィックサンプルに基づいて推定されます。より正確なトラフィック統計情報については、Grafanaの**<a href="/grafana-tikv-dashboard.md#tikv-details-dashboard">TiKV-Details</a>**ダッシュボードの`Log Backup`行目を確認してください。
+-   `speed(est.)` : ログバックアップの現在のデータ転送速度。この値は、過去数秒間に取得されたトラフィックサンプルに基づいて推定されます。より正確なトラフィック統計情報については、Grafanaの**<a href="/grafana-tikv-dashboard.md#tikv-details-dashboard">TiKV-Details</a>**ダッシュボードの`Log Backup`行を確認してください。
 -   `checkpoint[global]` : ログバックアップの現在の進行状況。PITRを使用して、このタイムスタンプより前の時点に復元できます。
 
 ログバックアップタスクが一時停止されている場合、 `log status`コマンドは一時停止の詳細を表示するための追加フィールドを出力します。これらは次のとおりです。

br/br-pitr-manual.md

@@ -547,9 +547,9 @@ tiup br restore point --pd="${PD_IP}:2379" \
 > -   フィルター オプションは、スナップショット バックアップとログ バックアップの両方の復元フェーズ中に適用されます。
 > -   複数の`--filter`オプションを指定して、異なるパターンを含めたり除外したりできます。
 > -   PITRフィルタリングはシステムテーブルをまだサポートしていません。特定のシステムテーブルを復元する必要がある場合は、代わりにフィルターを指定した`br restore full`コマンドを使用してください。このコマンドはスナップショットバックアップデータのみを復元し、ログバックアップデータは復元しないことに注意してください。
-> -   復元タスク内の正規表現は、 `restored-ts`番目の時点でのテーブル名と一致し、次の 3 つのケースが考えられます。
->     -   テーブルA（テーブルID = 1）：テーブル名は、 `restored-ts`番目の時点以前において、常に`--filter`正規表現と一致します。この場合、PITRはテーブルを復元します。
->     -   テーブルB（テーブルID = 2）：テーブル名は`restored-ts`より前の時点では`--filter`正規表現と一致しませんでしたが、 `restored-ts`番目の時点では一致しました。この場合、PITRはテーブルを復元します。
+> -   復元タスク内の正規表現は、 `restored-ts`時点でのテーブル名と一致し、次の 3 つのケースが考えられます。
+>     -   テーブルA（テーブルID = 1）：テーブル名は、 `restored-ts`時点以前において、常に`--filter`正規表現と一致します。この場合、PITRはテーブルを復元します。
+>     -   テーブルB（テーブルID = 2）：テーブル名は`restored-ts`より前の時点では`--filter`正規表現と一致しませんでしたが、 `restored-ts`時点では一致しました。この場合、PITRはテーブルを復元します。
 >     -   テーブルC（テーブルID = 3）：テーブル名は、 `restored-ts`より前の時点では正規表現`--filter`と一致していましたが、 `restored-ts`時点では一致**していません**。この場合、PITRはテーブルを復元しませ**ん**。
 > -   データベースとテーブルのフィルタリング機能を使用して、データの一部をオンラインで復元できます。オンライン復元プロセス中は、復元されたオブジェクトと同じ名前のデータベースまたはテーブルを作成し**ないで**ください。そうしないと、競合が発生して復元タスクが失敗します。データの不整合を回避するため、この復元プロセス中にPITRによって作成されたテーブルは、復元タスクが完了するまで読み取りも書き込みもできません。
 

cached-tables.md

@@ -53,7 +53,7 @@ Query OK, 0 rows affected (0.01 sec)
 
 ### キャッシュされたテーブルを検証する {#verify-a-cached-table}
 
-キャッシュされたテーブルを検証するには、 `SHOW CREATE TABLE`ステートメントを使用します。テーブルがキャッシュされている場合、返される結果には`CACHED ON`番目の属性が含まれます。
+キャッシュされたテーブルを検証するには、 `SHOW CREATE TABLE`ステートメントを使用します。テーブルがキャッシュされている場合、返される結果には`CACHED ON`属性が含まれます。
 
 ```sql
 SHOW CREATE TABLE users;

command-line-flags-for-tidb-configuration.md

@@ -122,7 +122,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション
 -   [PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)を使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト。
 -   デフォルト: `""`
 -   通常、リバースプロキシを経由してTiDBにアクセスする場合、TiDBはリバースプロキシサーバーのIPアドレスをクライアントのIPアドレスとして取得します。PROXYプロトコルを有効にすると、HAProxyなどのこのプロトコルをサポートするリバースプロキシは、実際のクライアントIPアドレスをTiDBに渡すことができます。
--   このフラグを設定すると、TiDBは設定された送信元IPアドレスがPROXYプロトコルを使用してTiDBに接続することを許可します。PROXY以外のプロトコルが使用されている場合、この接続は拒否されます。その他のアドレスはPROXYプロトコルを使用せずにTiDBに接続できます。このフラグを空のままにすると、どのIPアドレスもPROXYプロトコルを使用してTiDBに接続できなくなります。値は、IPアドレス（192.168.1.50）またはCIDR（192.168.1.0/24）で、区切り文字として`,`を使用します。`*`は任意のIPアドレスを意味します。
+-   このフラグを設定すると、TiDBは設定された送信元IPアドレスがPROXYプロトコルを使用してTiDBに接続することを許可します。PROXY以外のプロトコルが使用されている場合、この接続は拒否されます。その他のアドレスはPROXYプロトコルを使用せずにTiDBに接続できます。このフラグを空のままにすると、どのIPアドレスもPROXYプロトコルを使用してTiDBに接続できなくなります。値は、IPアドレス（192.168.1.50）またはCIDR（192.168.1.0/24）で、区切り文字として`,`を使用します。`*`任意のIPアドレスを意味します。
 
 > **Warning:**
 >

constraints.md

@@ -315,7 +315,7 @@ INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill');
 
         ERROR 8147 (23000): transaction aborted because lazy uniqueness check is enabled and an error occurred: [kv:1062]Duplicate entry 'bill' for key 'users.username'
 
--   この変数が無効になっている場合、 `1062 Duplicate entry`エラーは現在の SQL 文に起因しない可能性があります。そのため、トランザクションが同じ名前のインデックスを持つ複数のテーブルを操作する場合、 `1062`番目のエラーメッセージを確認して、実際にどのインデックスにエラーが発生しているかを特定する必要があります。
+-   この変数が無効になっている場合、 `1062 Duplicate entry`エラーは現在の SQL 文に起因しない可能性があります。そのため、トランザクションが同じ名前のインデックスを持つ複数のテーブルを操作する場合、 `1062`エラーメッセージを確認して、実際にどのインデックスにエラーが発生しているかを特定する必要があります。
 
 ## 主キー {#primary-key}
 

dashboard/dashboard-key-visualizer.md

@@ -114,7 +114,7 @@ Key Visualizer を開くと、デフォルトで過去 6 時間のデータベ
 
 ![Select metrics](/media/dashboard/dashboard-keyviz-select-type.png)
 
-関心のあるメトリックを表示するには**、メトリック選択ボックス**(上記のインターフェイスの`Write (bytes)`番目の位置) でこのメトリックを選択します。
+関心のあるメトリックを表示するには**、メトリック選択ボックス**(上記のインターフェイスの`Write (bytes)`の位置) でこのメトリックを選択します。
 
 -   `Read (bytes)` : トラフィックを読み取ります。
 -   `Write (bytes)` : トラフィックを書き込みます。