From b18070f2de35d15abca5069e9bfbbf78be0871ce Mon Sep 17 00:00:00 2001
From: Hirotaka Mizutani <52546+hirotaka@users.noreply.github.com>
Date: Tue, 16 Nov 2021 16:36:29 +0900
Subject: [PATCH 1/2] docs: translate docs/guides/auth/row-level-security

---
 TRANSLATION.md                              |   2 +
 web/docs/guides/auth/row-level-security.mdx | 148 ++++++++++----------
 web/prh.yml                                 |  68 ++++++---
 3 files changed, 124 insertions(+), 94 deletions(-)

diff --git a/TRANSLATION.md b/TRANSLATION.md
index 981a8be87..fa60fe889 100644
--- a/TRANSLATION.md
+++ b/TRANSLATION.md
@@ -33,6 +33,8 @@
 - 技術文書向けの[textlintルールのプリセット](https://github.com/textlint-ja/textlint-rule-preset-ja-technical-writing)に従います。
 - JTFの[スタイルガイド](https://www.jtf.jp/tips/translation_quality_guidelines)に準拠します。textlintの[ルール](https://github.com/textlint-ja/textlint-rule-preset-JTF-style)がはいっておりすべてのチェックが有効になっています。
 - ルールが厳しかったり、他のオープンソースプロジェクトの翻訳で採用しているスタイルと異なる事も多々あるので、随時調整してきます。何か提案がありましたら、[Discussion](https://github.com/hirotaka/supabase-ja/discussions)に投稿してください。
+- PostgreSQLの用語は日本PostgreSQLユーザ会の翻訳ドキュメントに従います。ただし、カタカナ語の語尾の長音はJTFのルールを優先しています。
+  https://www.postgresql.jp/
 
 ### 用語の統一
 
diff --git a/web/docs/guides/auth/row-level-security.mdx b/web/docs/guides/auth/row-level-security.mdx
index bc428c0f7..e8200fda1 100644
--- a/web/docs/guides/auth/row-level-security.mdx
+++ b/web/docs/guides/auth/row-level-security.mdx
@@ -1,21 +1,19 @@
 ---
 id: row-level-security
-title: Row Level Security
-description: Secure your data using Postgres Row Level Security.
+title: 行単位セキュリティー
+description: Postgresの行単位セキュリティーを使用してデータを保護します。
 ---
 
-When you need granular authorization rules, nothing beats PostgreSQL's [Row Level Security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html). 
+細かな認証ルールが必要な場合、PostgreSQLの[行単位セキュリティー（Row Level Security - RLS）](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)に勝るものはありません。
 
-[Policies](https://www.postgresql.org/docs/current/sql-createpolicy.html) are PostgreSQL's rule engine. They are incredibly powerful and flexible, allowing you to write complex SQL rules which fit your unique business needs.
+[ポリシー](https://www.postgresql.org/docs/current/sql-createpolicy.html)はPostgreSQLのルール・エンジンです。非常に強力で柔軟性があり、固有のビジネス・ニーズに合った複雑なSQLルールを書くことができます。
 
 <iframe className="w-full video-with-border" width="640" height="385" src="https://www.youtube-nocookie.com/embed/Ow_Uzedfohk" frameBorder="1" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
 
 
-## Policies
+## ポリシー
 
-Policies are easy to understand once you get the hang of them. Each policy is attached to a table, and the policy is executed
-every time a table is accessed.
-You can just think of them as adding a `WHERE` clause to every query. For example a policy like this ...
+ポリシーはコツをつかめば簡単に理解できます。各ポリシーはテーブルに関連付けられており、テーブルにアクセスするたびポリシーが実行されます。ポリシーは、すべての問い合わせに`WHERE`句を追加するようなものだと考えることができます。例えば、次のようなポリシーがあります。
 
 ```sql
 create policy "Individuals can view their own todos." 
@@ -23,86 +21,86 @@ create policy "Individuals can view their own todos."
     using ( auth.uid() = user_id );
 ```
 
-.. would translate to this whenever a user tries to select from the todos table:
+これは、ユーザーがtodosテーブルから選択しようとするたびに、このように変換されます。
 
 ```sql
 select *
 from todos
-where auth.uid() = todos.user_id; -- Policy is implicitly added.
+where auth.uid() = todos.user_id; -- ポリシーが暗黙の内に追加されます。
 ```
 
-## Helper Functions 
+## ヘルパー関数
 
-Supabase provides you with a few easy functions that you can use with your policies.
+Supabaseには、ポリシーで使用できる簡単な関数がいくつか用意されています。
 
 
-### `auth.uid()` 
+### `auth.uid()`
 
-Returns the ID of the user making the request.
+リクエストを行ったユーザーのIDを返します。
 
 ### `auth.role()`
 
-Returns the role of the user making the request. In most cases this is either `authenticated` or `anon`.
+リクエストを行ったユーザーのロールを返します。ほとんどの場合、これは`authenticated`（認証済み）または`anon`（匿名）のいずれかです。
 
 ### `auth.email()`
 
-Returns the email of the user making the request.
+リクエストを行ったユーザーのメール・アドレスを返します。
 
-## Examples
+## 例
 
-Here are some examples to show you the power of PostgreSQL's RLS. 
+以下に、PostgreSQLのRLSの能力を示す例を示します。
 
-### Allow read access
+### 読み取りアクセスの許可
 
 ```sql
--- 1. Create table
+-- 1. テーブルの作成
 create table profiles (
   id uuid references auth.users,
   avatar_url text
 );
 
--- 2. Enable RLS
+-- 2. RLSを有効化
 alter table profiles
   enable row level security;
 
--- 3. Create Policy
+-- 3. ポリシーを作成
 create policy "Public profiles are viewable by everyone."
   on profiles for select using (
     true
   );
 ```
 
-1. Creates a table called `profiles` in the public schema (default schema).
-2. Enables Row Level Security.
-3. Creates a policy which allows all `select` queries to run.
+1. パブリック・スキーマ（デフォルトスキーマ）に`profiles`というテーブルを作成します。
+2. 行単位セキュリティーを有効にします。
+3. すべての`select`クエリの実行を許可するポリシーを作成します。
 
-### Restrict updates
+### 更新の制限
 
 ```sql
--- 1. Create table
+-- 1. テーブルを作成
 create table profiles (
   id uuid references auth.users,
   avatar_url text
 );
 
--- 2. Enable RLS
+-- 2. RLSを有効化
 alter table profiles
   enable row level security;
 
--- 3. Create Policy
+-- 3. ポリシーを作成
 create policy "Users can update their own profiles."
   on profiles for update using (
     auth.uid() = id
   );
 ```
 
-1. Creates a table called `profiles` in the public schema (default schema).
-2. Enables RLS.
-3. Creates a policy which allows logged in users to update their own data.
+1. パブリック・スキーマ（デフォルト・スキーマ）に`profiles`というテーブルを作成します。
+2. RLSを有効にします。
+3. ログインしたユーザーが自分のデータを更新することを許可するポリシーを作成します。
 
-### Policies with joins
+### 結合を含むポリシー
 
-Policies can even include table joins. This example shows how you can query "external" tables to build more advanced rules.
+ポリシーには、テーブルの結合を含めることもできます。この例では、より高度なルールを構築するために、「外部」のテーブルにクエリを実行する方法を示しています。
 
 ```sql
 create table teams (
@@ -110,17 +108,17 @@ create table teams (
   name text
 );
 
--- 2. Create many to many join
+-- 2. 多対多の結合を作成
 create table members (
   team_id bigint references teams,
   user_id uuid references auth.users
 );
 
--- 3. Enable RLS
+-- 3. RLSを有効化
 alter table teams
   enable row level security;
 
--- 4. Create Policy
+-- 4. ポリシーを作成
 create policy "Team members can update team details if they belong to the team."
   on teams
   for update using (
@@ -131,18 +129,18 @@ create policy "Team members can update team details if they belong to the team."
   );
 ```
 
-### Policies with security definer functions
+### security definer関数を使ったポリシー
 
-Policies can also make use of `security definer functions`. This is useful in a many-to-many relationship where you want to restrict access to the linking table. Following the `teams` and `members` example from above, this example shows how you can use security definer function in combination with a policy to control access to the `members` table.
+ポリシーには、`security definer関数`も使用できます。これは、多対多の関係で、リンク先のテーブルへのアクセスを制限したい場合に便利です。この例では、上記の`teams`と`members`の例に続いて、security definer関数をポリシーと組み合わせて使用し、`members`テーブルへのアクセスを制御する方法を示します。
 
 ```sql
--- 1. Follow example for 'Policies with joins' above
+-- 1. 上記の「結合を含むポリシー」の例に従います
 
--- 2.  Enable RLS
+-- 2. RLSを有効化
 alter table members
   enable row level security
 
--- 3.  Create security definer function
+-- 3. security definer関数を作成
 create or replace function get_teams_for_authenticated_user()
 returns setof bigint
 language sql
@@ -155,7 +153,7 @@ as $$
     where user_id = auth.uid()
 $$;
 
--- 4. Create Policy
+-- 4. ポリシーを作成
 create policy "Team members can update team members if they belong to the team."
   on members
   for all using (
@@ -166,23 +164,22 @@ create policy "Team members can update team members if they belong to the team."
 
 ```
 
-### Verifying email domains
+### メール・アドレスのドメインを検証
 
-Postgres has a function `right(string, n)` that returns the rightmost n characters of a string.
-You could use this to match staff member's email domains.
+Postgresには、文字列の右端n文字を返す関数`right(string, n)`があります。これを使用して、スタッフのメール・アドレスのドメインを照合できます。
 
 ```sql
--- 1. Create table
+-- 1. テーブルを作成
 create table leaderboard (
   id uuid references auth.users,
   high_score bigint
 );
 
--- 2. Enable RLS
+-- 2. RLSを有効化
 alter table leaderboard
   enable row level security;
 
--- 3. Create Policy
+-- 3. ポリシーを作成
 create policy "Only Blizzard staff can update leaderboard"
   on leaderboard
   for update using (
@@ -190,24 +187,24 @@ create policy "Only Blizzard staff can update leaderboard"
   );
 ```
 
-### Time to live for rows
+### 行のTTL（Time to live - 生存時間）
 
-Policies can also be used to implement TTL or time to live feature that you see in Instagram stories or Snapchat.
-In the following example, rows of `stories` table are available only if they have been created within the last 24 hours.
+InstagramのストリーズやSnapchatで見られるTTL（Time To Live）機能を実装するためにも利用できます。
+次の例では、`stories`テーブルの行は、過去24時間以内に作成された場合にのみ利用可能です。
 
 ```sql
--- 1. Create table
+-- 1. テーブルを作成
 create table if not exists stories (
   id uuid not null primary key DEFAULT uuid_generate_v4(),
   created_at timestamp with time zone default timezone('utc' :: text, now()) not null,
   content text not null
 );
 
--- 2. Enable RLS
+-- 2. RLSを有効化
 alter table stories
   enable row level security;
 
--- 3. Create Policy
+-- 3. ポリシーを作成
 create policy "Stories are live for a day"
   on stories
   for select using (
@@ -215,12 +212,11 @@ create policy "Stories are live for a day"
   );
 ```
 
-### Advanced policies
+### 高度なポリシー
 
-Use the full power of SQL to build extremely advanced rules.
+SQLの機能をフルに活用して、極めて高度なルールを構築ができます。
 
-In this example, we will create a `posts` and `comments` tables and then create a policy that depends on another policy.
-(In this case, the comments policy depends on the posts policy.)
+この例では、`posts`テーブルと`comments`テーブルを作成し、別のポリシーに依存するポリシーを作成します（この場合、commentsポリシーはpostsポリシーに依存します）。
 
 ```sql
 create table posts (
@@ -268,46 +264,44 @@ using (
 
 ## Tips
 
-### Disable realtime for private tables
+### プライベートなテーブルのリアルタイムを無効化
 
-Our realtime server doesn't provide per-user security. Until we build a more robust auth system for WebSockets, you can disable realtime functionality for any private tables. To do this, you can manage the underlying Postgres replication publication:
+私たちのリアルタイム・サーバーは、ユーザーごとのセキュリティーを提供していません。WebSocket用の、より強固な認証システムを構築するまでの間、プライベートなテーブルのリアルタイム機能を無効にできます。これを行うには、基盤となるPostgresレプリケーションのパブリケーションによって制御します。
 
 ```sql
 /**
- * REALTIME SUBSCRIPTIONS
- * Only allow realtime listening on public tables.
+ * リアルタイム・サブスクリプション
+ * 公開されたテーブルでのみ、リアルタイムでのリスニングを許可する。
  */
 
 begin;
-  -- remove the realtime publication
+  -- リアルタイムのパブリケーションを削除
   drop publication if exists supabase_realtime;
 
-  -- re-create the publication but don't enable it for any tables
+  -- パブリケーションを再作成しますが、どのテーブルに対しても有効にしません
   create publication supabase_realtime;
 commit;
 
--- add a table to the publication
+-- パブリケーションにテーブルを追加
 alter publication supabase_realtime add table products;
 
--- add other tables to the publication
+-- パブリケーションに他のテーブルを追加
 alter publication supabase_realtime add table posts;
 ```
 
-We're in the process of building [enhanced realtime security](https://github.com/supabase/walrus).
+私たちは、[強化したリアルタイムのセキュリティ](https://github.com/supabase/walrus)を実装しているところです。
 
-### You don't have to use policies 
+### ポリシーを使用する必要はありません
 
-You can also put your authorization rules in your middleware, similar to how you would create security rules with any other `backend <-> middleware <-> frontend` architecture.
+他の`バックエンド <-> ミドルウェア <-> フロントエンド`のアーキテクチャでセキュリティ・ルールを作成するのと同じように、ミドルウェアに認証ルールを置くこともできます。
 
-Policies are a tool. In the case of "serverless/Jamstack" setups, they are especially effective because you don't have to deploy any middleware at all.
+ポリシーはツールです。「サーバーレス/Jamstack」による構成の場合は、ミドルウェアを一切導入する必要がないので、特に効果的です。
 
-However, if you want to use another authorization method for your applications, that's also fine. Supabase is "just Postgres", so if your application 
-works with Postgres, then it also works with Supabase. 
+しかし、アプリケーションに別の認証方法を使用したい場合は、それも問題ありません。Supabaseは「単なるPostgres」ですので、Postgresで動作するアプリケーションであれば、Supabaseでも動作します。
 
-Tip: Make sure to enable RLS for all your tables, so that your tables are inaccessible. Then use the "Service" which we provide, which is designed to bypass RLS.
+Tips：すべてのテーブルに対してRLSを有効化して、テーブルへアクセスできないようにしてください。その上で、RLSをバイパスするように設計された私たちの「サービス」をご利用ください。
 
 
-### Never use a service key on the client
+### クライアントでサービス・キーを使用しない
 
-Supabase provides special "Service" keys, which can be used to bypass all RLS. 
-These should never be used in the browser or exposed to customers, but they are useful for administrative tasks.
+Supabaseは、RLSを回避するための特別な「サービス」キーを提供しています。これらのキーは、決してブラウザーで使用したり、ユーザーに公開したりしてはいけませんが、管理作業には便利です。
diff --git a/web/prh.yml b/web/prh.yml
index a812e5a50..8188e08a0 100644
--- a/web/prh.yml
+++ b/web/prh.yml
@@ -1,5 +1,8 @@
 version: 1
 rules:
+  #
+  # Supabase関連
+  #
   - expected: Supabase
     pattern:
       - /supabase(.)?/
@@ -12,15 +15,6 @@ rules:
      - from: supabase
        to: Supabase
 
-  - expected: Postgres
-    pattern:
-      - postgre
-
-  - expected: Firebase
-    pattern:
-      - firebase
-      - ファイアーベース
-
   # 製品名として使われる場合はこのまま
   - expected: Supabase Storage
     pattern:
@@ -62,11 +56,47 @@ rules:
       # 上記のプロジェクト名の場合とコンフリクトするのでコメントアウト
       # - Realtime
 
-  - expected: 行レベルセキュリティー
+  - expected: パブリック・スキーマ
+    pattern:
+      - public schema
+      - /公開・スキーマ/
+
+  - expected: パブリック・テーブル
+    pattern:
+      - public table
+      - /公開・テーブル/
+
+  - expected: プライベート
+    pattern:
+      - 非公開
+
+  #
+  # PotgreSQL関連用語
+  # https://github.com/pgsql-jp/taiyaku
+  #
+  - expected: 行単位セキュリティー
     pattern:
       - Row Level Security
       - ロウレベルセキュリティー
       - ロウ・レベル・セキュリティー
+      - 行レベルセキュリティー
+
+  - expected: 結合
+    pattern:
+      - join
+      - ジョイン
+
+  #
+  # 技術系用語
+  #
+  - expected: Postgres
+    pattern:
+      - postgre
+
+  - expected: Firebase
+    pattern:
+      - firebase
+      - ファイアーベース
 
   - expected: バケット
     options:
@@ -80,13 +110,17 @@ rules:
     pattern:
       - エクセル
 
-  - expected: パブリック・テーブル
-    pattern: /公開・テーブル/
-
-  - expected: プライベート
-    pattern:
-      - 非公開
-
   - expected: RESTful API
     pattern:
       - レストフルAPI
+
+  #
+  # 一般用語
+  #
+  - expected: 私たちの
+    pattern:
+      - our
+      - 我々の
+      - われわれの
+      - 私達の
+

From 46250e4ed5f0da2e98cc82701614f16bac61b27b Mon Sep 17 00:00:00 2001
From: Hirotaka Mizutani <52546+hirotaka@users.noreply.github.com>
Date: Tue, 16 Nov 2021 16:45:14 +0900
Subject: [PATCH 2/2] fix textlint

---
 web/.textlintignore                                 |  3 ++-
 web/docs/learn/auth-deep-dive/google-oauth.md       |  2 +-
 web/docs/learn/auth-deep-dive/gotrue.md             |  2 +-
 web/docs/learn/auth-deep-dive/jwts.md               |  8 ++++----
 web/docs/learn/auth-deep-dive/policies.md           |  4 ++--
 web/docs/learn/auth-deep-dive/row-level-security.md | 10 +++++-----
 web/prh.yml                                         |  2 ++
 7 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/web/.textlintignore b/web/.textlintignore
index 9876a23fe..5658c8a04 100644
--- a/web/.textlintignore
+++ b/web/.textlintignore
@@ -9,10 +9,12 @@ docs/guides.md
 docs/guides/auth/auth-apple.mdx
 docs/guides/auth/auth-bitbucket.mdx
 docs/guides/auth/auth-discord.mdx
+docs/guides/auth/auth-email.mdx
 docs/guides/auth/auth-facebook.mdx
 docs/guides/auth/auth-github.mdx
 docs/guides/auth/auth-gitlab.mdx
 docs/guides/auth/auth-google.mdx
+docs/guides/auth/auth-magic-link.mdx
 docs/guides/auth/auth-messagebird.mdx
 docs/guides/auth/auth-slack.mdx
 docs/guides/auth/auth-spotify.mdx
@@ -21,7 +23,6 @@ docs/guides/auth/auth-twitch.mdx
 docs/guides/auth/auth-twitter.mdx
 docs/guides/auth/intro.mdx
 docs/guides/auth/managing-user-data.mdx
-docs/guides/auth/row-level-security.mdx
 docs/guides/client-libraries.mdx
 docs/guides/database/arrays.mdx
 docs/guides/database/connecting/connecting-to-postgres.mdx
diff --git a/web/docs/learn/auth-deep-dive/google-oauth.md b/web/docs/learn/auth-deep-dive/google-oauth.md
index dc0b2370c..0d1fa3f53 100644
--- a/web/docs/learn/auth-deep-dive/google-oauth.md
+++ b/web/docs/learn/auth-deep-dive/google-oauth.md
@@ -84,7 +84,7 @@ https://<自身のを参照>.supabase.co/auth/v1/authorize?provider=google&https
 
 ### 次のステップ
 - [パート1：JWT](/docs/learn/auth-deep-dive/auth-deep-dive-jwts)をみる
-- [パート2：行レベルセキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)をみる
+- [パート2：行単位セキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)をみる
 - [パート3：ポリシー](/docs/learn/auth-deep-dive/auth-policies)をみる
 - [パート4：GoTrue](/docs/learn/auth-deep-dive/auth-gotrue)をみる
 <!-- - [パート5：Google Oauth](/docs/learn/auth-deep-dive/auth-google-oauth)をみる -->
diff --git a/web/docs/learn/auth-deep-dive/gotrue.md b/web/docs/learn/auth-deep-dive/gotrue.md
index 799609d5e..5276b5604 100644
--- a/web/docs/learn/auth-deep-dive/gotrue.md
+++ b/web/docs/learn/auth-deep-dive/gotrue.md
@@ -69,7 +69,7 @@ const { user, session, error } = await supabase.auth.signIn({
 ### 次のステップ
 
 - [パート1：JWT](/docs/learn/auth-deep-dive/auth-deep-dive-jwts)をみる
-- [パート2：行レベルセキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)をみる
+- [パート2：行単位セキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)をみる
 - [パート3：ポリシー](/docs/learn/auth-deep-dive/auth-policies)をみる
 <!-- - [パート4：GoTrue](/docs/learn/auth-deep-dive/auth-gotrue)をみる -->
 - [パート5：Google Oauth](/docs/learn/auth-deep-dive/auth-google-oauth)をみる
diff --git a/web/docs/learn/auth-deep-dive/jwts.md b/web/docs/learn/auth-deep-dive/jwts.md
index 6e2040e31..f92dd0543 100644
--- a/web/docs/learn/auth-deep-dive/jwts.md
+++ b/web/docs/learn/auth-deep-dive/jwts.md
@@ -107,7 +107,7 @@ HMACSHA256(
 Supabaseでは、3つの異なる目的のためにJWTを発行しています。
 
 1. `匿名キー（anon key）`：このキーはSupabase APIゲートウェイをバイパスするために使用され、クライアント・サイドのコードで使用できます。
-2. `サービス・ロール・キー（service role key）`：このキーはスーパー・アドミン権限を持ち、行レベルセキュリティーを回避できます。このキーをクライアント・サイドのコードに入れないでください。秘密にしておいてください。
+2. `サービス・ロール・キー（service role key）`：このキーはスーパー・アドミン権限を持ち、行単位セキュリティーを回避できます。このキーをクライアント・サイドのコードに入れないでください。秘密にしておいてください。
 3. `ユーザー固有のjwts`：これは、あなたのプロジェクトやサービス、ウェブサイトへログインしたユーザーに発行するトークンです。これは現代のセッション・トークンに相当するもので、ユーザーは自分固有のコンテンツやパーミッションへアクセスするために使用できます。
 
 最初のトークンである`匿名キー`トークンは、開発者がSupabaseのデータベースとやり取りする際に、APIリクエストと一緒に送信するためのものです。
@@ -131,7 +131,7 @@ curl 'https://xscduanzzfseqszwzhcy.supabase.co/rest/v1/colors?select=name' \
 
 このJWTは、開発者のSupabaseトークンに固有の`jwt_secret`で署名されています。このシークレットは、ダッシュボードの「Settings」→「API」ページで、エンコードされた「匿名キー（anon key）」と一緒に確認できます。Supabase APIゲートウェイを通過して、開発者のプロジェクトへアクセスするために必要となります。
 
-しかし、このシリーズの[パート2](/docs/learn/auth-deep-dive/auth-row-level-security)のテーマである「行レベルセキュリティー」を有効にした場合、このキーをエンドユーザーが見ても問題ないことになります。
+しかし、このシリーズの[パート2](/docs/learn/auth-deep-dive/auth-row-level-security)のテーマである「行単位セキュリティー」を有効にした場合、このキーをエンドユーザーが見ても問題ないことになります。
 
 2つ目のキーである`サービス・ロール・キー`は、自分のサーバーや環境でのみ使用し、エンドユーザーとは決して共有してはいけません。このトークンを使って、データの一括挿入などを行うことができます。
 
@@ -165,7 +165,7 @@ curl 'https://xscduanzzfseqszwzhcy.supabase.co/rest/v1/colors?select=name' \
 }
 ```
 
-JWTとは何か、そしてSupabaseのどこで使われているかを解説しました。その上で、Postgresデータベースの特定のテーブル、行、列へのアクセスを制限します。そのために、行レベルセキュリティーと組み合わせてJWTを使用する方法を「[パート2：行レベルセキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)」で探ってみましょう。
+JWTとは何か、そしてSupabaseのどこで使われているかを解説しました。その上で、Postgresデータベースの特定のテーブル、行、列へのアクセスを制限します。そのために、行単位セキュリティーと組み合わせてJWTを使用する方法を「[パート2：行レベルセキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)」で探ってみましょう。
 
 ### リソース
 
@@ -176,7 +176,7 @@ JWTとは何か、そしてSupabaseのどこで使われているかを解説し
 <!-- - Watch [Part One: JWTs](/docs/learn/auth-deep-dive/auth-deep-dive-jwts) -->
 
 <!-- - [パート2：Part Two: Row Level Security](/docs/learn/auth-deep-dive/auth-row-level-security) -->
-- [パート2：行レベルセキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)
+- [パート2：行単位セキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)
 - [パート3：ポリシー](/docs/learn/auth-deep-dive/auth-policies)
 - [パート4：GoTrue](/docs/learn/auth-deep-dive/auth-gotrue)
 - [パート5：Google Oauth](/docs/learn/auth-deep-dive/auth-google-oauth)
diff --git a/web/docs/learn/auth-deep-dive/policies.md b/web/docs/learn/auth-deep-dive/policies.md
index 3b306d06a..d7dc90a58 100644
--- a/web/docs/learn/auth-deep-dive/policies.md
+++ b/web/docs/learn/auth-deep-dive/policies.md
@@ -159,12 +159,12 @@ PostgreSQLのポリシーに関する完全なドキュメントは次のURLを
 
 - JWTデバッガー：[https://jwt.io](https://jwt.io%E2%80%8B)
 - PostgeSQLポリシー：https://www.postgresql.org/docs/12/sql-createpolicy.html
-- PostgREST行レベルセキュリティー：https://postgrest.org/en/v7.0.0/auth.html
+- PostgREST行単位セキュリティー：https://postgrest.org/en/v7.0.0/auth.html
 
 ### 次のステップ
 
 - [パート1：JWT](/docs/learn/auth-deep-dive/auth-deep-dive-jwts)をみる
-- [パート2：行レベルセキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)をみる
+- [パート2：行単位セキュリティー](/docs/learn/auth-deep-dive/auth-row-level-security)をみる
 <!-- - [パート3：ポリシー](/docs/learn/auth-deep-dive/auth-policies)をみる -->
 - [パート4：GoTrue](/docs/learn/auth-deep-dive/auth-gotrue)をみる
 - [パート5：Google Oauth](/docs/learn/auth-deep-dive/auth-google-oauth)をみる
diff --git a/web/docs/learn/auth-deep-dive/row-level-security.md b/web/docs/learn/auth-deep-dive/row-level-security.md
index 301433f3b..c402439d9 100644
--- a/web/docs/learn/auth-deep-dive/row-level-security.md
+++ b/web/docs/learn/auth-deep-dive/row-level-security.md
@@ -1,12 +1,12 @@
 ---
 id: auth-row-level-security
-title: 'パート2：行レベルセキュリティー'
-description: Supabase Auth詳細：パート2 - 行レベルセキュリティー
+title: 'パート2：行単位セキュリティー'
+description: Supabase Auth詳細：パート2 - 行単位セキュリティー
 ---
 
 ### 概要
 
-Supabaseダッシュボードで行レベルセキュリティーを有効にし、Postgresポリシーを記述することで、データベース・テーブルへのアクセスを制限する方法を紹介します。
+Supabaseダッシュボードで行単位セキュリティーを有効にし、Postgresポリシーを記述することで、データベース・テーブルへのアクセスを制限する方法を紹介します。
 
 ### 視聴
 
@@ -25,7 +25,7 @@ const supabase = createClient(
 
 しかし、これは興味深い問題を提起しています。「もし私の匿名キーがクライアントにあるならば、誰かが私のjavascriptを読んでキーを盗むことができるではないか」、答えはイエスです。ここで、Postgresのポリシーが登場します。
 
-Postgresの「行レベルセキュリティー」ポリシーを使用して、匿名キーがどのデータに対してアクセスを許可するかしないかのルールをデフォルトで設定できます。
+Postgresの「行単位セキュリティー」ポリシーを使用して、匿名キーがどのデータに対してアクセスを許可するかしないかのルールをデフォルトで設定できます。
 
 例えば、匿名キーは特定のテーブルからの読み込みを許可し、書き込み、更新、削除はできないようにできます。
 
@@ -66,7 +66,7 @@ ALTER TABLE leaderboard ENABLE ROW LEVEL SECURITY;
 
 または、Supabaseのダッシュボードから、「Auth」→「Policies」と進み、リーダーボード・テーブルにある赤い錠をクリックして白にしてください。
 
-![Supabaseで行レベルセキュリティーを有効にする](/img/auth-deep-dive-2.png)
+![Supabaseで行単位セキュリティーを有効にする](/img/auth-deep-dive-2.png)
 
 読み込みや書き込みも、次のようなエラーで失敗してしまうことでしょう。
 
diff --git a/web/prh.yml b/web/prh.yml
index 8188e08a0..ec23b354f 100644
--- a/web/prh.yml
+++ b/web/prh.yml
@@ -118,6 +118,8 @@ rules:
   # 一般用語
   #
   - expected: 私たちの
+    options:
+      wordBoundary: true
     pattern:
       - our
       - 我々の