diff --git a/guides/source/ja/active_job_basics.md b/guides/source/ja/active_job_basics.md index a282d5f034..0cd7c26eec 100644 --- a/guides/source/ja/active_job_basics.md +++ b/guides/source/ja/active_job_basics.md @@ -330,7 +330,7 @@ NOTE: 優先度の低い番号が、優先度の高い番号より先に実行 コールバック --------- -Active Jobが提供するフックを用いて、ジョブのライフサイクル中にロジックをトリガできます。これらのコールバックは、Railsの他のコールバックと同様に通常のメソッドとして実装し、マクロ風のクラスメソッドでコールバックとして登録できます。 +Active Jobが提供するフックを用いて、ジョブのライフサイクル中にロジックをトリガーできます。これらのコールバックは、Railsの他のコールバックと同様に通常のメソッドとして実装し、マクロ風のクラスメソッドでコールバックとして登録できます。 ```ruby class GuestsCleanupJob < ApplicationJob diff --git a/guides/source/ja/active_record_callbacks.md b/guides/source/ja/active_record_callbacks.md index 563a73a8ea..476dd78cd2 100644 --- a/guides/source/ja/active_record_callbacks.md +++ b/guides/source/ja/active_record_callbacks.md @@ -536,7 +536,7 @@ Book/Libraryがtouchされました コールバックの実行 ----------------- -以下のメソッドはコールバックをトリガします。 +以下のメソッドはコールバックをトリガーします。 * `create` * `create!` @@ -932,7 +932,7 @@ WARNING: `before_destroy`コールバックを使う場合は、レコードが` データベースのトランザクションが完了したときにトリガーされるコールバックが2つあります。[`after_commit`][]と[`after_rollback`][]です。 -これらのコールバックは`after_save`コールバックときわめて似ていますが、データベースの変更のコミットまたはロールバックが完了するまでトリガされない点が異なります。これらのメソッドは、Active Recordのモデルから、データベーストランザクションの一部に含まれていない外部のシステムとやりとりしたい場合に特に便利です。 +これらのコールバックは`after_save`コールバックときわめて似ていますが、データベースの変更のコミットまたはロールバックが完了するまでトリガーされない点が異なります。これらのメソッドは、Active Recordのモデルから、データベーストランザクションの一部に含まれていない外部のシステムとやりとりしたい場合に特に便利です。 例として、`PictureFile`モデルで、対応するレコードが削除された後にファイルを1つ削除する必要があるとしましょう。 @@ -973,7 +973,7 @@ class PictureFile < ApplicationRecord end ``` -NOTE: `:on`オプションは、コールバックがトリガされるタイミングを指定します。`:on`オプションを指定しないと、すべてのアクションでコールバックがトリガされます。詳しくは[`:on`の利用方法](#ライフサイクルイベントで実行されるコールバックを登録する)を参照してください。 +NOTE: `:on`オプションは、コールバックがトリガーされるタイミングを指定します。`:on`オプションを指定しないと、すべてのアクションでコールバックがトリガーされます。詳しくは[`:on`の利用方法](#ライフサイクルイベントで実行されるコールバックを登録する)を参照してください。 トランザクションが完了すると、そのトランザクション内で作成・更新・破棄されたすべてのモデルに対して`after_commit`コールバックまたは`after_rollback`コールバックが呼び出されます。ただし、これらのコールバックのいずれかで例外が発生した場合、その例外はバブルアップされ、残りの`after_commit`や`after_rollback`メソッドは実行されません。 diff --git a/guides/source/ja/active_record_migrations.md b/guides/source/ja/active_record_migrations.md index 4d69b78cf4..b445c9d4c4 100644 --- a/guides/source/ja/active_record_migrations.md +++ b/guides/source/ja/active_record_migrations.md @@ -1231,7 +1231,7 @@ end #### `:sql`スキーマダンプを利用する場合 -しかし、`db/schema.rb`では、「トリガ」「シーケンス」「ストアドプロシージャ」「チェック制約」などのデータベース固有の項目までは表現できません。 +しかし、`db/schema.rb`では、「トリガー」「シーケンス」「ストアドプロシージャ」「チェック制約」などのデータベース固有の項目までは表現できません。 マイグレーションで`execute`を用いれば、RubyマイグレーションDSLでサポートされないデータベース構造も作成できますが、そうしたステートメントはスキーマダンプで再構成されないので、注意が必要です。 diff --git a/guides/source/ja/active_record_querying.md b/guides/source/ja/active_record_querying.md index 74f9a72885..64b8508e1d 100644 --- a/guides/source/ja/active_record_querying.md +++ b/guides/source/ja/active_record_querying.md @@ -2364,7 +2364,7 @@ irb> Customer.pluck(:first_name) irb> Order.joins(:customer, :books).pluck("orders.created_at, customers.email, books.title") ``` -さらに`pluck`は、`select`などの`Relation`スコープと異なり、クエリを直接トリガするので、その後ろに他のスコープをチェインできません。ただし、構成済みのスコープを`pluck`の前に置くことは可能です。 +さらに`pluck`は、`select`などの`Relation`スコープと異なり、クエリを直接トリガーするので、その後ろに他のスコープをチェインできません。ただし、構成済みのスコープを`pluck`の前に置くことは可能です。 ```irb irb> Customer.pluck(:first_name).limit(1) @@ -2631,7 +2631,7 @@ EXPLAIN SELECT "customers".* FROM "customers" INNER JOIN "orders" ON "orders"."c (7 rows) ``` -eager loadingを使うと、内部的には複数のクエリがトリガされることがあり、このとき一部のクエリが先行するクエリの結果を必要とすることがあります。このためexplainは、このクエリを実際に実行した後で、クエリプランを要求します。以下に例を示します。 +eager loadingを使うと、内部的には複数のクエリがトリガーされることがあり、このとき一部のクエリが先行するクエリの結果を必要とすることがあります。このためexplainは、このクエリを実際に実行した後で、クエリプランを要求します。以下に例を示します。 ```ruby Customer.where(id: 1).includes(:orders).explain diff --git a/guides/source/ja/active_record_validations.md b/guides/source/ja/active_record_validations.md index 58ea27ebfe..cc410d8bac 100644 --- a/guides/source/ja/active_record_validations.md +++ b/guides/source/ja/active_record_validations.md @@ -74,9 +74,9 @@ irb> p.new_record? 新規レコードを作成して保存すると、SQLの`INSERT`操作がデータベースに送信されます。既存のレコードを更新すると、SQLの`UPDATE`操作が送信されます。バリデーションは、SQLのデータベースへの送信前に行うのが普通です。バリデーションのいずれかが失敗すると、オブジェクトは無効（invalid）とマークされ、Active Recordでの`INSERT`や`UPDATE`操作は行われません。これにより、無効なオブジェクトがデータベースに保存されないようにします。オブジェクトの作成、保存、更新時に特定のバリデーションを実行することもできます。 CAUTION: データベース上のオブジェクトの状態を変える方法が多数あることにご注意ください。 -メソッドには、バリデーションをトリガするものと、しないものがあります。この点に注意しておかないと、バリデーションが設定されているにもかかわらず、データベース上のオブジェクトが無効な状態になってしまう可能性があります。 +メソッドには、バリデーションをトリガーするものと、しないものがあります。この点に注意しておかないと、バリデーションが設定されているにもかかわらず、データベース上のオブジェクトが無効な状態になってしまう可能性があります。 -以下のメソッドではバリデーションがトリガされ、オブジェクトが有効な場合にのみデータベースに保存されます。 +以下のメソッドではバリデーションがトリガーされ、オブジェクトが有効な場合にのみデータベースに保存されます。 * [`create`][] * [`create!`][] @@ -147,7 +147,7 @@ CAUTION: データベース上のオブジェクトの状態を変える方法 Railsは、Active Recordオブジェクトを保存する直前にバリデーションを実行します。バリデーションで何らかのエラーが発生すると、オブジェクトを保存しません。 -[`valid?`][]メソッドを使って、バリデーションを手動でトリガすることもできます。`valid?`を実行するとバリデーションがトリガされ、オブジェクトにエラーがない場合は`true`を返し、エラーの場合は`false`を返します。 +[`valid?`][]メソッドを使って、バリデーションを手動でトリガーすることもできます。`valid?`を実行するとバリデーションがトリガーされ、オブジェクトにエラーがない場合は`true`を返し、エラーの場合は`false`を返します。 これは以下のように実装できます。 ```ruby @@ -200,7 +200,7 @@ irb> Person.create! ActiveRecord::RecordInvalid: Validation failed: Name can't be blank ``` -[`invalid?`][]は`valid?`と逆のチェックを行います。このメソッドはバリデーションをトリガし、オブジェクトでエラーが発生した場合は`true`を返し、エラーがない場合は`false`を返します。 +[`invalid?`][]は`valid?`と逆のチェックを行います。このメソッドはバリデーションをトリガーし、オブジェクトでエラーが発生した場合は`true`を返し、エラーがない場合は`false`を返します。 [`errors`]: https://api.rubyonrails.org/classes/ActiveModel/Validations.html#method-i-errors [`invalid?`]: https://api.rubyonrails.org/classes/ActiveModel/Validations.html#method-i-invalid-3F @@ -210,7 +210,7 @@ ActiveRecord::RecordInvalid: Validation failed: Name can't be blank [`errors[:attribute]`][Errors#squarebrackets]を使うと、特定のオブジェクトの属性が有効かどうかを確認できます。このメソッドは、`:attribute`のすべてのエラーの配列を返します。指定された属性でエラーが発生しなかった場合は、空の配列が返されます。 -このメソッドが役に立つのは、バリデーションを実行した**後**だけです。このメソッドはエラーのコレクションを調べるだけで、バリデーションそのものをトリガしないからです。このメソッドは、前述の`ActiveRecord::Base#invalid?`メソッドとは異なります。このメソッドはオブジェクト全体の正当性については確認せず、オブジェクトの個別の属性についてエラーがあるかどうかだけを調べます。 +このメソッドが役に立つのは、バリデーションを実行した**後**だけです。このメソッドはエラーのコレクションを調べるだけで、バリデーションそのものをトリガーしないからです。このメソッドは、前述の`ActiveRecord::Base#invalid?`メソッドとは異なります。このメソッドはオブジェクト全体の正当性については確認せず、オブジェクトの個別の属性についてエラーがあるかどうかだけを調べます。 ```ruby class Person < ApplicationRecord diff --git a/guides/source/ja/active_support_core_extensions.md b/guides/source/ja/active_support_core_extensions.md index 672cd361c3..81de215538 100644 --- a/guides/source/ja/active_support_core_extensions.md +++ b/guides/source/ja/active_support_core_extensions.md @@ -3368,7 +3368,7 @@ NOTE: 定義は[`active_support/core_ext/date_and_time/calculations.rb`](https:/ ##### `weeks_ago`、`weeks_since` -[`weeks_ago`][DateAndTime::Calculations#weeks_ago]メソッドや[`weeks_since`][DateAndTime::Calculations#week_since]メソッドは、同じ要領で週に対して行います。 +[`weeks_ago`][DateAndTime::Calculations#weeks_ago]メソッドや[`weeks_since`][DateAndTime::Calculations#weeks_since]メソッドは、同じ要領で週に対して行います。 ```ruby Date.new(2010, 5, 24).weeks_ago(1) # => Mon, 17 May 2010 diff --git a/guides/source/ja/association_basics.md b/guides/source/ja/association_basics.md index 73152a6df5..1510d126bb 100644 --- a/guides/source/ja/association_basics.md +++ b/guides/source/ja/association_basics.md @@ -2565,7 +2565,7 @@ NOTE: `:counter_cache`オプションは、関連付けの`belongs_to`側にだ [通常のコールバック](active_record_callbacks.html)は、Active Recordオブジェクトのライフサイクルの中でフックされます。これにより、さまざまなタイミングでオブジェクトのコールバックを実行できます。たとえば、`:before_save`コールバックを使うと、オブジェクトが保存される直前に何かを実行できます。 -関連付けのコールバックも、上のような通常のコールバックと似ていますが、（Active Recordオブジェクトではなく）コレクションのライフサイクルによってイベントがトリガされる点が異なります。関連付けでは、以下の4つのコールバックを利用できます。 +関連付けのコールバックも、上のような通常のコールバックと似ていますが、（Active Recordオブジェクトではなく）コレクションのライフサイクルによってイベントがトリガーされる点が異なります。関連付けでは、以下の4つのコールバックを利用できます。 * `before_add` * `after_add` diff --git a/guides/source/ja/autoloading_and_reloading_constants_classic_mode.md b/guides/source/ja/autoloading_and_reloading_constants_classic_mode.md index 487d991bdb..09b32965c4 100644 --- a/guides/source/ja/autoloading_and_reloading_constants_classic_mode.md +++ b/guides/source/ja/autoloading_and_reloading_constants_classic_mode.md @@ -523,7 +523,7 @@ Admin::User > 見つからない定数が、そのクラスまたはモジュールの親の名前空間にも存在しない場合、Railsはこの定数を相対参照であると仮定する。そうでない場合は修飾済み参照であると仮定する。 -たとえば、以下のコードが自動読み込みをトリガし、 +たとえば、以下のコードが自動読み込みをトリガーし、 ```ruby Admin::User @@ -1065,7 +1065,7 @@ ActiveSupport::Dependencies.logger = Rails.logger ActiveSupport::Dependencies.verbose = true ``` -### トリガされたこの自動読み込みはどこにあるか？ +### トリガーされたこの自動読み込みはどこにあるか？ 定数`Foo`が自動読み込みされている最中で、その自動読み込みがどこから来たのかを知りたい場合は、`foo.rb`のトップに以下を書いて、出力されたスタックトレースを精査します。 diff --git a/guides/source/ja/security.md b/guides/source/ja/security.md index 2d449e6dbd..ccdd0c14df 100644 --- a/guides/source/ja/security.md +++ b/guides/source/ja/security.md @@ -740,7 +740,7 @@ s = sanitize(user_input, tags: tags, attributes: %w(href title)) この方法なら指定されたタグのみが許可されるため、あらゆる攻撃方法や悪質なタグに対してフィルタが正常に機能します。 -Action ViewとAction Textは、どちらも[rails-html-sanitizer][] gemの上に[サニタイズヘルパー][[sanitization helpers]]を構築しています。 +Action ViewとAction Textは、どちらも[rails-html-sanitizer][] gemの上に[サニタイズヘルパー][sanitization helpers]を構築しています。 第2段階として、**Webアプリケーションからの出力を1つ残らずエスケープする**ことが優れた対策となります。これは特に、ユーザー入力の段階でフィルタされなかった文字列がWeb画面に再表示された場合に有効です。**`html_escape()`（または別名の`h()`）メソッド**を用いて、HTML入力文字（`&`、`"`、`<`、`>`）を無害なHTML表現形式（`&`、`"`、`<`、`>`）に置き換えます。 diff --git a/guides/source/ja/testing.md b/guides/source/ja/testing.md index 90f5d7ef0a..6a3543bb0f 100644 --- a/guides/source/ja/testing.md +++ b/guides/source/ja/testing.md @@ -427,7 +427,7 @@ Railsは`minitest`フレームワークに以下のような独自のカスタ -**[`assert_difference(expressions, difference = 1, message = nil) {...}`][]** +**[`assert_difference(expressions, difference = 1, message = nil)`][]** * `yield`されたブロックで評価された結果である式の戻り値における数値の違いをテストする。 @@ -463,7 +463,7 @@ Railsは`minitest`フレームワークに以下のような独自のカスタ * 渡されたリダイレクトオプションが、最後に実行されたアクションで呼び出されたリダイレクトのオプションと一致することを主張する。`assert_redirected_to root_path`などの名前付きルートを渡すことも、`assert_redirected_to @article`などのActive Recordオブジェクトを渡すことも可能。 -[`assert_queries_count(count = nil, include_schema: false, &block)`][]** +**[`assert_queries_count(count = nil, include_schema: false, &block)`][]** * `&block`がSQLクエリの`int`数値を生成することを主張する。 @@ -479,7 +479,7 @@ Railsは`minitest`フレームワークに以下のような独自のカスタ * `&block`が指定のパターンにマッチするSQLクエリを生成しないことを主張する。 -[`assert_difference(expressions, difference = 1, message = nil) {...}`]: https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_difference) +[`assert_difference(expressions, difference = 1, message = nil)`]: https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_difference [`assert_no_difference(expressions, message = nil, &block)`]: https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_no_difference [`assert_changes(expressions, message = nil, from:, to:, &block)`]: https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_changes [`assert_no_changes(expressions, message = nil, &block)`]: https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_no_changes @@ -904,7 +904,7 @@ Railsはデフォルトで、`test/fixtures`フォルダにあるすべてのフ 2. フィクスチャのデータをテーブルに読み込む 3. フィクスチャに直接アクセスしたい場合はフィクスチャのデータをメソッドにダンプする -TIP: Railsでは、データベースから既存のデータベースを削除するために外部キーやチェック制約といった参照整合性（referential integrity）トリガを無効にしようとします。テスト実行時のパーミッションエラーが発生して困っている場合は、test環境のデータベースユーザーがこれらのトリガを無効にする特権を持っていることをご確認ください（PostgreSQLの場合、すべてのトリガを無効にできるのはsuperuserのみです。PostgreSQLのパーミッションについて詳しくは[こちらの記事](https://www.postgresql.jp/document/current/html/sql-altertable.html)を参照してください）。 +TIP: Railsでは、データベースから既存のデータベースを削除するために外部キーやチェック制約といった参照整合性（referential integrity）トリガーを無効にしようとします。テスト実行時のパーミッションエラーが発生して困っている場合は、test環境のデータベースユーザーがこれらのトリガーを無効にする特権を持っていることをご確認ください（PostgreSQLの場合、すべてのトリガーを無効にできるのはsuperuserのみです。PostgreSQLのパーミッションについて詳しくは[こちらの記事](https://www.postgresql.jp/document/current/html/sql-altertable.html)を参照してください）。 #### フィクスチャはActive Recordオブジェクト diff --git a/guides/source/ja/threading_and_code_execution.md b/guides/source/ja/threading_and_code_execution.md index af594803ac..86caa0be32 100644 --- a/guides/source/ja/threading_and_code_execution.md +++ b/guides/source/ja/threading_and_code_execution.md @@ -125,7 +125,7 @@ Rackミドルウェアである`ActionDispatch::Executor`と`ActionDispatch::Rel Active Jobでもジョブ実行をReloaderでラップし、キューに積まれた各ジョブを実行するときに最新のコードが読み込まれるようにします。 -Action CableではReloaderではなくExecutorが使われます。Action Cableコネクションはクラスの特定のインスタンスに紐付けられていて、Websocketメッセージが到着するたびに再読み込みすることが不可能なためです。Action Cableではメッセージハンドラのみがラップされるので、長時間実行されるAction Cableコネクションでも、新しく到着したリクエストやジョブによってトリガされる再読み込みはブロックされません。代わりに、Action CableはReloaderの`before_class_unload`コールバックを用いてすべてのコネクションを切断します。クライアントが自動的に再接続すると、そのことが新バージョンのコードに伝わります。 +Action CableではReloaderではなくExecutorが使われます。Action Cableコネクションはクラスの特定のインスタンスに紐付けられていて、Websocketメッセージが到着するたびに再読み込みすることが不可能なためです。Action Cableではメッセージハンドラのみがラップされるので、長時間実行されるAction Cableコネクションでも、新しく到着したリクエストやジョブによってトリガーされる再読み込みはブロックされません。代わりに、Action CableはReloaderの`before_class_unload`コールバックを用いてすべてのコネクションを切断します。クライアントが自動的に再接続すると、そのことが新バージョンのコードに伝わります。 上記はフレームワークのエントリポイントなので、それぞれのコンポーネントは自身のスレッド群が保護されていることを確認し、再読み込みが必要かどうかを決定する責務を負います。その他のコンポーネントは、追加のスレッドを生成するためだけにExecutorを必要とします。 @@ -216,6 +216,6 @@ config.middleware.insert_before Rack::Sendfile, ActionDispatch::DebugLocks ``` -追加後アプリケーションを再起動してデッドロック条件を再度トリガすると、`/rails/locks`で「Load Interlockで現在認識されているすべてのスレッド」「それらが現在保持または待機しているロックのレベル」「それらの現在のバックトレース」の概要が表示されるようになります。 +追加後アプリケーションを再起動してデッドロック条件を再度トリガーすると、`/rails/locks`で「Load Interlockで現在認識されているすべてのスレッド」「それらが現在保持または待機しているロックのレベル」「それらの現在のバックトレース」の概要が表示されるようになります。 デッドロックは一般に、Load Interlockが他の外部ロックやブロッキングI/O呼び出しと競合することで発生します。デッドロックに気づいたら、`permit_concurrent_loads`でラップできます。