i18n(ja): repair sentences scrambled by the translation pipeline

ai/integrations/vector-search-auto-embedding-cohere.md

@@ -72,7 +72,7 @@ CREATE TABLE sample (
 
 > **Note:**
 >
-> -   Cohere埋め込みモデルの場合、テーブルを定義する際に、{{ `input_type` `EMBED_TEXT()` }を指定する必要があります。例えば、 `'{"input_type": "search_document", "input_type@search": "search_query"}'`は、データ挿入時に`input_type`が`search_document`に設定され、ベクトル検索時に`search_query`が自動的に適用されることを意味します。
+> -   Cohere埋め込みモデルの場合、テーブルを定義する際に、 `EMBED_TEXT()`関数で`input_type`を指定する必要があります。例えば、 `'{"input_type": "search_document", "input_type@search": "search_query"}'`は、データ挿入時に`input_type`が`search_document`に設定され、ベクトル検索時に`search_query`が自動的に適用されることを意味します。
 > -   `@search`サフィックスは、そのフィールドがベクトル検索クエリの実行時のみ有効であることを示しています。そのため、クエリを作成する際に`input_type`を再度指定する必要はありません。
 
 データ挿入とデータ照会：

ai/quickstart-via-sql.md

@@ -143,7 +143,7 @@ SELECT * FROM embedded_documents;
 
 この例では、検索語は「泳ぐ動物」であり、それに対応するベクトル埋め込みは`[1,2,3]`であると想定されています。実際のアプリケーションでは、埋め込みモデルを使用して、ユーザーの検索語をベクトル埋め込みに変換する必要があります。
 
-次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `[1,2,3]`計算してソートすることにより、 `vec_cosine_distance` } に最も近い上位 3 つのドキュメントを特定します。
+次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `vec_cosine_distance` ) を計算してソートすることにより、 `[1,2,3]`に最も近い上位 3 つのドキュメントを特定します。
 
 ```sql
 SELECT id, document, vec_cosine_distance(embedding, '[1,2,3]') AS distance

br/br-snapshot-guide.md

@@ -134,7 +134,7 @@ tiup br restore table --pd "${PD_IP}:2379" \
 
 **テーブルフィルターを使用して複数のテーブルを復元します。**
 
-より複雑なフィルタルールを持つ複数のテーブルを復元するには、 `tiup br restore full`コマンド[テーブルフィルター](/table-filter.md)実行し、 `--filter`または`-f`を使用してテーブルを指定します。次の例では`db*.tbl*`フィルタルールに一致するテーブルをバックアップデータからターゲットクラスタに復元します。
+より複雑なフィルタルールを持つ複数のテーブルを復元するには、 `tiup br restore full`コマンドを実行し、 `--filter`または`-f`を使用して[テーブルフィルター](/table-filter.md)を指定します。次の例では`db*.tbl*`フィルタルールに一致するテーブルをバックアップデータからターゲットクラスタに復元します。
 
 ```shell
 tiup br restore full \

data-type-date-and-time.md

@@ -175,7 +175,7 @@ CREATE TABLE t1 (
 
 ## 時間値の小数部分 {#decimal-part-of-time-value}
 
-`DATETIME`と`TIMESTAMP`値は、マイクロ秒単位の精度で最大 6 桁の小数部を持つことができます`DATETIME`型または`TIMESTAMP`型の列では、小数部は破棄されずに保存されます。小数部がある場合、値は「YYYY-MM-DD HH:MM:SS[.fraction]」の形式で表され、小数部の範囲は 000000 から 999999 です。小数部と残りの部分を区切るために小数点を使用する必要があります。
+`DATETIME`と`TIMESTAMP`値は、マイクロ秒単位の精度で最大 6 桁の小数部を持つことができます。 `DATETIME`型または`TIMESTAMP`型のいずれかの列では、小数部は破棄されずに保存されます。小数部がある場合、値は「YYYY-MM-DD HH:MM:SS[.fraction]」の形式で表され、小数部の範囲は 000000 から 999999 です。小数部と残りの部分を区切るために小数点を使用する必要があります。
 
 -   小数精度をサポートする列を定義するには`type_name(fsp)`使用します。3 `type_name` `TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、
 

develop/dev-guide-create-table.md

@@ -230,7 +230,7 @@ CREATE TABLE `bookshop`.`users` (
 >
 > このセクションで説明する手順は、クイック スタートとテスト***のみ***を目的としています。 TiDB での HTAP の使用法の詳細については、 [HTAPを探索する](/explore-htap.md)参照してください。
 
-`ratings`アプリケーションを使用して`bookshop`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合`score`フィールドと`rated_at` `ratings` } フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。
+`bookshop`アプリケーションを使用して`ratings`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合、 `ratings`テーブル全体の`score`フィールドと`rated_at`フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。
 
 このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。
 

dm/dm-error-handling.md

@@ -146,7 +146,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機
 
 3.  アップストリーム内の対応するbinlogファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。
 
-4.  リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid` ～ `true`指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。
+4.  リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid`を`true`に指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。
 
     例: エラーが発生した場合、 `binlog-name = "mysql-bin.004451"`と`binlog-pos = 2453`をそれぞれ`binlog-name = "mysql-bin.004452"`と`binlog-pos = 4`に更新し、 `binlog-gtid`を`f0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058`に更新します。
 
@@ -192,7 +192,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ
 
     デフォルトの`--statement-size`設定によると、ダンプ処理ユニットによって生成されるデフォルトのサイズ`Insert Statement`は約`1M`です。このデフォルト設定では、ロード処理ユニットはほとんどの場合、エラー`packet for query is too large. Try adjusting the 'max_allowed_packet' variable`報告しません。
 
-    データダンプ中に、以下のログが`WARN`出力されることがあります。この`WARN`はダンプ処理には影響しません。これは、幅の広いテーブルがダンプされたことを示しているだけです。
+    データダンプ中に、以下の`WARN`ログが出力されることがあります。この`WARN`ログはダンプ処理には影響しません。これは、幅の広いテーブルがダンプされたことを示しているだけです。
 
         Row bigger than statement_size for xxx
 

dm/maintain-dm-using-tiup.md

@@ -161,7 +161,7 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262
 
 > **Note:**
 >
-> v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)サポートします。
+> v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)をサポートします。
 >
 > アップグレード前に、 `config export`使用してクラスターの設定ファイルをエクスポートできます。アップグレード後に以前のバージョンにダウングレードする必要がある場合は、まず以前のクラスターを再デプロイし、 `config import`使用して以前の設定ファイルをインポートできます。
 >

encryption-at-rest.md

@@ -74,13 +74,13 @@ TiKVは現在、 CTRモードでAES128、AES192、AES256、またはSM4（バー
     data-encryption-method = "aes128-ctr"
     data-key-rotation-period = "168h" # 7 days
 
--   `data-encryption-method`暗号化アルゴリズムを指定します。指定可能な値は`"aes128-ctr"` 、 `"aes192-ctr"` 、 `"aes256-ctr"` 、 `"sm4-ctr"` （v6.3.0以降のバージョンのみ）、 `"plaintext"`です。デフォルト値は`"plaintext"`で、暗号化はデフォルトで無効になっています。
+-   `data-encryption-method`は、暗号化アルゴリズムを指定します。指定可能な値は`"aes128-ctr"` 、 `"aes192-ctr"` 、 `"aes256-ctr"` 、 `"sm4-ctr"` （v6.3.0以降のバージョンのみ）、 `"plaintext"`です。デフォルト値は`"plaintext"`で、暗号化はデフォルトで無効になっています。
 
     -   新しい TiKV クラスターまたは既存の TiKV クラスターの場合、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。
     -   暗号化を有効にした後に無効にするには、構成ファイルから`data-encryption-method`削除するか、その値を`"plaintext"`に設定して、TiKV を再起動します。
     -   暗号化アルゴリズムを変更するには、値`data-encryption-method`をサポートされている暗号化アルゴリズムに置き換え、TiKVを再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルが、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。
 
--   `data-key-rotation-period` 、TiKV がキーをローテーションする頻度を指定します。
+-   `data-key-rotation-period`は、TiKV がキーをローテーションする頻度を指定します。
 
 暗号化が有効になっている場合（つまり、 `data-encryption-method`値が`"plaintext"`ではない場合）、次のいずれかの方法でマスター キーを指定する必要があります。
 
@@ -305,7 +305,7 @@ AWS でキーを作成するには、TiKV のキーを作成する手順を参
 
 `data-encryption-method`に指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、「sm4-ctr」（v6.4.0 以降のみ）、「plaintext」です。デフォルト値は「plaintext」で、暗号化は無効です。3 `data-key-rotation-period` 、 TiFlash がデータキーをローテーションする頻度を定義します。暗号化は、新規TiFlashクラスターまたは既存のTiFlashクラスターで有効にできますが、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルの`data-encryption-method`削除するか、「plaintext」にリセットし、 TiFlashを再起動します。暗号化方式を変更するには、設定ファイルの`data-encryption-method`更新し、 TiFlash を再起動します。暗号化アルゴリズムを変更するには、 `data-encryption-method`サポートされている暗号化アルゴリズムに置き換え、 TiFlash を再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルは、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。
 
-暗号化が有効になっている場合（つまり、 `data-encryption-method` 「プレーンテキスト」ではない場合）、マスターキーを指定する必要があります。AWS KMS CMK をマスターキーとして指定するには、 `tiflash-learner.toml`設定ファイルの`encryption`セクションの後に`encryption.master-key`セクションを追加します。
+暗号化が有効になっている場合（つまり、 `data-encryption-method`が「プレーンテキスト」ではない場合）、マスターキーを指定する必要があります。AWS KMS CMK をマスターキーとして指定するには、 `tiflash-learner.toml`設定ファイルの`encryption`セクションの後に`encryption.master-key`セクションを追加します。
 
     [security.encryption.master-key]
     type = "kms"

faq/backup-and-restore-faq.md

@@ -176,9 +176,9 @@ BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-cre
 
 TiKVがバックアップディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKVに書き込み権限があるかどうかを確認してください。データを復元するには、TiKVに読み取り権限があるかどうかを確認してください。
 
-バックアップ操作中、ストレージメディアがローカルディスクまたはネットワークファイルシステム（NFS）の場合、 `br`起動するユーザーとTiKVを起動するユーザーが一致していることを確認してください（ `br`とTiKVが異なるマシン上にある場合は、ユーザーのUIDが一致している必要があります）。一致していない場合、 `Permission denied`問題が発生する可能性があります。
+バックアップ操作中、ストレージメディアがローカルディスクまたはネットワークファイルシステム（NFS）の場合、 `br`を起動するユーザーとTiKVを起動するユーザーが一致していることを確認してください（ `br`とTiKVが異なるマシン上にある場合は、ユーザーのUIDが一致している必要があります）。一致していない場合、 `Permission denied`問題が発生する可能性があります。
 
-バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、ディスク権限が原因で`br` `root`ユーザーとして実行すると失敗する可能性があります。
+バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、ディスク権限が原因で`br`を`root`ユーザーとして実行すると失敗する可能性があります。
 
 > **Note:**
 >

foreign-key.md

@@ -66,7 +66,7 @@ ReferenceOption
 `UPDATE`または`DELETE`操作が親テーブルの外部キー値に影響を与える場合、子テーブルの対応する外部キー値は、外部キー定義の`ON UPDATE`または`ON DELETE`句で定義された参照操作によって決定されます。参照操作には、次のものが含まれます。
 
 -   `CASCADE` : `UPDATE`または`DELETE`操作が親テーブルに影響を与える場合、子テーブルの対応する行を自動的に更新または削除します。カスケード操作は深さ優先で実行されます。
--   `SET NULL` : `NULL`操作が親テーブルに影響を与える場合、子テーブルの対応する外部キー列を自動的に {{B `UPDATE` `DELETE`に設定します。
+-   `SET NULL` : `UPDATE`または`DELETE`操作が親テーブルに影響を与える場合、子テーブルの対応する外部キー列を自動的に`NULL`に設定します。
 -   `RESTRICT` : 子テーブルに一致する行が含まれている場合、 `UPDATE`または`DELETE`操作を拒否します。
 -   `NO ACTION` : `RESTRICT`と同じです。
 -   `SET DEFAULT` : `RESTRICT`と同じです。

functions-and-operators/json-functions/json-functions-validate.md

@@ -139,7 +139,7 @@ SELECT JSON_SCHEMA_VALID('{"required": ["fruits","vegetables","grains"]}',@j);
     +------------------------------------------------------------------------+
     1 row in set (0.00 sec)
 
-上記の出力から、 `fruits` 、 `vegetables` 、 `grains` }}属性の存在検証が、 `grains`存在しないため失敗していることがわかります。
+上記の出力から、 `fruits` 、 `vegetables` 、 `grains`属性の存在検証が、 `grains`が存在しないため失敗していることがわかります。
 
 `fruits`が配列であることを検証します。
 

functions-and-operators/window-functions.md

@@ -99,7 +99,7 @@ FROM (
 
 ## `FIRST_VALUE()` {#first-value}
 
-`FIRST_VALUE(expr)`ウィンドウ内の最初の値を返します。
+`FIRST_VALUE(expr)`は、ウィンドウ内の最初の値を返します。
 
 次の例では、 2 つの異なるウィンドウ定義を使用しています。
 
@@ -136,7 +136,7 @@ ORDER BY
 
 ## `LAG()` {#lag}
 
-`LAG(expr [, num [, default]])`関数は、現在行の`num`行前にある行の値`expr`を返します。そのような行が存在しない場合は、 `default`が返されます。デフォルトでは、 `num`は`1`は`default` `NULL`扱われます。
+`LAG(expr [, num [, default]])`関数は、現在行の`num`行前にある行の値`expr`を返します。そのような行が存在しない場合は、 `default`が返されます。デフォルトでは、指定されていない場合、 `num`は`1` 、 `default`は`NULL`として扱われます。
 
 次の例では、 `num`指定されていないため、 `LAG(n)`前の行の`n`の値を返します。7が`n`の場合、前の行は存在せず、 `default`指定されていないため、 `LAG(1)`は`NULL`返します。