3 files changed, 17 insertions, 10 deletions
diff --git a/guides/source/form_helpers.md b/guides/source/form_helpers.md
index ec4a255398..455dc7bebe 100644
--- a/guides/source/form_helpers.md
+++ b/guides/source/form_helpers.md
@@ -751,7 +751,7 @@ You might want to render a form with a set of edit fields for each of a person's
 <%= form_for @person do |person_form| %>
   <%= person_form.text_field :name %>
   <% @person.addresses.each do |address| %>
-    <%= person_form.fields_for address, index: address do |address_form|%>
+    <%= person_form.fields_for address, index: address.id do |address_form|%>
       <%= address_form.text_field :city %>
     <% end %>
   <% end %>
@@ -774,9 +774,16 @@ This will result in a `params` hash that looks like
 {'person' => {'name' => 'Bob', 'address' => {'23' => {'city' => 'Paris'}, '45' => {'city' => 'London'}}}}
 ```
 
-Rails knows that all these inputs should be part of the person hash because you called `fields_for` on the first form builder. By specifying an `:index` option you're telling Rails that instead of naming the inputs `person[address][city]` it should insert that index surrounded by [] between the address and the city. If you pass an Active Record object as we did then Rails will call `to_param` on it, which by default returns the database id. This is often useful as it is then easy to locate which Address record should be modified. You can pass numbers with some other significance, strings or even `nil` (which will result in an array parameter being created).
+Rails knows that all these inputs should be part of the person hash because you
+called `fields_for` on the first form builder. By specifying an `:index` option
+you're telling Rails that instead of naming the inputs `person[address][city]`
+it should insert that index surrounded by [] between the address and the city.
+This is often useful as it is then easy to locate which Address record
+should be modified. You can pass numbers with some other significance,
+strings or even `nil` (which will result in an array parameter being created).
 
-To create more intricate nestings, you can specify the first part of the input name (`person[address]` in the previous example) explicitly, for example
+To create more intricate nestings, you can specify the first part of the input
+name (`person[address]` in the previous example) explicitly:
 
 ```erb
 <%= fields_for 'person[address][primary]', address, index: address do |address_form| %>
diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md
index ebc56cba58..dbcedba800 100644
--- a/guides/source/getting_started.md
+++ b/guides/source/getting_started.md
@@ -231,7 +231,7 @@ Rails will create several files and a route for you.
 
 ```bash
 create  app/controllers/welcome_controller.rb
- route  get "welcome/index"
+ route  get 'welcome/index'
 invoke  erb
 create    app/views/welcome
 create    app/views/welcome/index.html.erb
@@ -272,13 +272,13 @@ Open the file `config/routes.rb` in your editor.
 
 ```ruby
 Rails.application.routes.draw do
-  get "welcome/index"
+  get 'welcome/index'
 
   # The priority is based upon order of creation:
   # first created -> highest priority.
   #
   # You can have the root of your site routed with "root"
-  # root "welcome#index"
+  # root 'welcome#index'
   #
   # ...
 ```
@@ -295,7 +295,7 @@ root 'welcome#index'
 ```
 
 `root 'welcome#index'` tells Rails to map requests to the root of the
-application to the welcome controller's index action and `get "welcome/index"`
+application to the welcome controller's index action and `get 'welcome/index'`
 tells Rails to map requests to <http://localhost:3000/welcome/index> to the
 welcome controller's index action. This was created earlier when you ran the
 controller generator (`rails generate controller welcome index`).
@@ -328,7 +328,7 @@ Blog::Application.routes.draw do
 
   resources :posts
 
-  root "welcome#index"
+  root 'welcome#index'
 end
 ```
 
diff --git a/guides/source/security.md b/guides/source/security.md
index 21cc3deb8a..c367604d6f 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -150,7 +150,7 @@ Another countermeasure is to _save user-specific properties in the session_, ver
 
 ### Session Expiry
 
-NOTE: _Sessions that never expire extend the time-frame for attacks such as cross-site reference forgery (CSRF), session hijacking and session fixation._
+NOTE: _Sessions that never expire extend the time-frame for attacks such as cross-site request forgery (CSRF), session hijacking and session fixation._
 
 One possibility is to set the expiry time-stamp of the cookie with the session id. However the client can edit cookies that are stored in the web browser so expiring sessions on the server is safer. Here is an example of how to _expire sessions in a database table_. Call `Session.sweep("20 minutes")` to expire sessions that were used longer than 20 minutes ago.
 
@@ -354,7 +354,7 @@ Having one single place in the admin interface or Intranet, where the input has
 
 Refer to the Injection section for countermeasures against XSS. It is _recommended to use the SafeErb plugin_ also in an Intranet or administration interface.
 
-**CSRF** Cross-Site Reference Forgery (CSRF) is a gigantic attack method, it allows the attacker to do everything the administrator or Intranet user may do. As you have already seen above how CSRF works, here are a few examples of what attackers can do in the Intranet or admin interface.
+**CSRF** Cross-Site Request Forgery (CSRF), also known as Cross-Site Reference Forgery (XSRF), is a gigantic attack method, it allows the attacker to do everything the administrator or Intranet user may do. As you have already seen above how CSRF works, here are a few examples of what attackers can do in the Intranet or admin interface.
 
 A real-world example is a [router reconfiguration by CSRF](http://www.h-online.com/security/Symantec-reports-first-active-attack-on-a-DSL-router--/news/102352). The attackers sent a malicious e-mail, with CSRF in it, to Mexican users. The e-mail claimed there was an e-card waiting for them, but it also contained an image tag that resulted in a HTTP-GET request to reconfigure the user's router (which is a popular model in Mexico). The request changed the DNS-settings so that requests to a Mexico-based banking site would be mapped to the attacker's site. Everyone who accessed the banking site through that router saw the attacker's fake web site and had their credentials stolen.