prefer american spelling of 'behavior'

actionpack/lib/action_controller/metal/strong_parameters.rb

@@ -45,7 +45,7 @@ module ActionController
   #   # => #<Person id: 1, name: "Francesco", age: 22, role: "user">
   #
   # It provides a +permit_all_parameters+ option that controls the top-level
-  # behaviour of new instances. If it's +true+, all the parameters will be
+  # behavior of new instances. If it's +true+, all the parameters will be
   # permitted by default. The default value for +permit_all_parameters+
   # option is +false+.
   #

activemodel/lib/active_model/attribute_methods.rb

@@ -436,7 +436,7 @@ module ActiveModel
     # attribute_missing is like method_missing, but for attributes. When method_missing is
     # called we check to see if there is a matching attribute method. If so, we call
     # attribute_missing to dispatch the attribute. This method can be overloaded to
-    # customise the behaviour.
+    # customize the behavior.
     def attribute_missing(match, *args, &block)
       __send__(match.target, match.attr_name, *args, &block)
     end

activerecord/lib/active_record/associations.rb

@@ -951,7 +951,7 @@ module ActiveRecord
     #
     # The <tt>:dependent</tt> option can have different values which specify how the deletion
     # is done. For more information, see the documentation for this option on the different
-    # specific association types. When no option is given, the behaviour is to do nothing
+    # specific association types. When no option is given, the behavior is to do nothing
     # with the associated records when destroying a record.
     #
     # Note that <tt>:dependent</tt> is implemented using Rails' callback

activerecord/lib/active_record/associations/collection_proxy.rb

@@ -758,7 +758,7 @@ module ActiveRecord
       #   person.pets.count # => 0
       #   person.pets.any?  # => true
       #
-      # You can also pass a block to define criteria. The behaviour
+      # You can also pass a block to define criteria. The behavior
       # is the same, it returns true if the collection based on the
       # criteria is not empty.
       #
@@ -793,7 +793,7 @@ module ActiveRecord
       #   person.pets.many? #=> true
       #
       # You can also pass a block to define criteria. The
-      # behaviour is the same, it returns true if the collection
+      # behavior is the same, it returns true if the collection
       # based on the criteria has more than one record.
       #
       #   person.pets

activerecord/test/cases/deprecated_dynamic_methods_test.rb

@@ -1,7 +1,7 @@
 # This file should be deleted when activerecord-deprecated_finders is removed as
 # a dependency.
 #
-# It is kept for now as there is some fairly nuanced behaviour in the dynamic
+# It is kept for now as there is some fairly nuanced behavior in the dynamic
 # finders so it is useful to keep this around to guard against regressions if
 # we need to change the code.
 

activesupport/lib/active_support/core_ext/array/conversions.rb

@@ -8,7 +8,7 @@ class Array
   # Converts the array to a comma-separated sentence where the last element is
   # joined by the connector word.
   #
-  # You can pass the following options to change the default behaviour. If you
+  # You can pass the following options to change the default behavior. If you
   # pass an option key that doesn't exist in the list below, it will raise an
   # <tt>ArgumentError</tt>.
   #

activesupport/lib/active_support/json/encoding.rb

@@ -235,7 +235,7 @@ class BigDecimal
   # real value.
   #
   # Use <tt>ActiveSupport.use_standard_json_big_decimal_format = true</tt> to
-  # override this behaviour.
+  # override this behavior.
   def as_json(options = nil) #:nodoc:
     if finite?
       ActiveSupport.encode_big_decimal_as_string ? to_s : self

guides/source/configuring.md

@@ -585,7 +585,7 @@ Rails has 5 initialization events which can be hooked into (listed in the order
 
 * `to_prepare`: Run after the initializers are run for all Railties (including the application itself), but before eager loading and the middleware stack is built. More importantly, will run upon every request in `development`, but only once (during boot-up) in `production` and `test`.
 
-* `before_eager_load`: This is run directly before eager loading occurs, which is the default behaviour for the `production` environment and not for the `development` environment.
+* `before_eager_load`: This is run directly before eager loading occurs, which is the default behavior for the `production` environment and not for the `development` environment.
 
 * `after_initialize`: Run directly after the initialization of the application, but before the application initializers are run.
 

guides/source/engines.md

@@ -16,7 +16,7 @@ After reading this guide, you will know:
 What are engines?
 -----------------
 
-Engines can be considered miniature applications that provide functionality to their host applications. A Rails application is actually just a "supercharged" engine, with the `Rails::Application` class inheriting a lot of its behaviour from `Rails::Engine`.
+Engines can be considered miniature applications that provide functionality to their host applications. A Rails application is actually just a "supercharged" engine, with the `Rails::Application` class inheriting a lot of its behavior from `Rails::Engine`.
 
 Therefore, engines and applications can be thought of almost the same thing, just with very minor differences, as you'll see throughout this guide. Engines and applications also share a common structure.
 
@@ -647,7 +647,7 @@ This would then turn the above code for `set_author` into this:
 self.author = Blorgh.user_class.find_or_create_by(name: author_name)
 ```
 
-Resulting in something a little shorter, and more implicit in its behaviour. The `user_class` method should always return a `Class` object.
+Resulting in something a little shorter, and more implicit in its behavior. The `user_class` method should always return a `Class` object.
 
 To set this configuration setting within the application, an initializer should be used. By using an initializer, the configuration will be set up before the application starts and calls the engine's models which may depend on this configuration setting existing.
 

guides/source/i18n.md

@@ -897,7 +897,7 @@ The I18n API will catch all of these exceptions when they are thrown in the back
 
 The reason for this is that during development you'd usually want your views to still render even though a translation is missing.
 
-In other contexts you might want to change this behaviour, though. E.g. the default exception handling does not allow to catch missing translations during automated tests easily. For this purpose a different exception handler can be specified. The specified exception handler must be a method on the I18n module or a class with `#call` method:
+In other contexts you might want to change this behavior, though. E.g. the default exception handling does not allow to catch missing translations during automated tests easily. For this purpose a different exception handler can be specified. The specified exception handler must be a method on the I18n module or a class with `#call` method:
 
 ```ruby
 module I18n
@@ -927,7 +927,7 @@ else
 end
 ```
 
-Another example where the default behaviour is less desirable is the Rails TranslationHelper which provides the method `#t` (as well as `#translate`). When a `MissingTranslationData` exception occurs in this context, the helper wraps the message into a span with the CSS class `translation_missing`.
+Another example where the default behavior is less desirable is the Rails TranslationHelper which provides the method `#t` (as well as `#translate`). When a `MissingTranslationData` exception occurs in this context, the helper wraps the message into a span with the CSS class `translation_missing`.
 
 To do so, the helper forces `I18n#translate` to raise exceptions no matter what exception handler is defined by setting the `:raise` option:
 

guides/source/layouts_and_rendering.md

@@ -97,7 +97,7 @@ NOTE: The actual rendering is done by subclasses of `ActionView::TemplateHandler
 
 ### Using `render`
 
-In most cases, the `ActionController::Base#render` method does the heavy lifting of rendering your application's content for use by a browser. There are a variety of ways to customize the behaviour of `render`. You can render the default view for a Rails template, or a specific template, or a file, or inline code, or nothing at all. You can render text, JSON, or XML. You can specify the content type or HTTP status of the rendered response as well.
+In most cases, the `ActionController::Base#render` method does the heavy lifting of rendering your application's content for use by a browser. There are a variety of ways to customize the behavior of `render`. You can render the default view for a Rails template, or a specific template, or a file, or inline code, or nothing at all. You can render text, JSON, or XML. You can specify the content type or HTTP status of the rendered response as well.
 
 TIP: If you want to see the exact results of a call to `render` without needing to inspect it in a browser, you can call `render_to_string`. This method takes exactly the same options as `render`, but it returns a string instead of sending a response back to the browser.
 

guides/source/nested_model_forms.md

@@ -56,7 +56,7 @@ end
 
 ### Custom model
 
-As you might have inflected from this explanation, you _don’t_ necessarily need an ActiveRecord::Base model to use this functionality. The following examples are sufficient to enable the nested model form behaviour:
+As you might have inflected from this explanation, you _don’t_ necessarily need an ActiveRecord::Base model to use this functionality. The following examples are sufficient to enable the nested model form behavior:
 
 #### Single associated object