Style regular font for constants

4 files changed, 5 insertions, 5 deletions

diff --git a/railties/doc/guides/migrations/anatomy_of_a_migration.txt b/railties/doc/guides/migrations/anatomy_of_a_migration.txt
index 86b00c7185..456087c1af 100644
--- a/railties/doc/guides/migrations/anatomy_of_a_migration.txt
+++ b/railties/doc/guides/migrations/anatomy_of_a_migration.txt
@@ -23,7 +23,7 @@ end
 This migration adds a table called products with a string column called `name` and a text column called `description`. A primary key column called `id` will also be added, however since this is the default we do not need to ask for this. The timestamp columns `created_at` and `updated_at` which Active Record populates automatically will also be added. Reversing this migration is as simple as dropping the table.
 
 === Migrations are classes
-A migration is a subclass of `ActiveRecord::Migration` that implements two class methods: +up+ (perform the required transformations) and +down+ (revert them).
+A migration is a subclass of ActiveRecord::Migration that implements two class methods: +up+ (perform the required transformations) and +down+ (revert them).
 
 Active Record provides methods that perform common data definition tasks in a database independent way (you'll read about them in detail later):
 
@@ -44,7 +44,7 @@ On databases that support transactions with statements that change the schema, m
 
 === What's in a name ===
 
-Migrations are stored in files in db/migrate, one for each migration class. The name of the file is of the form `YYYYMMDDHHMMSS_create_products.rb`, that is to say a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration. The migration class' name must match (the camelcased version of) the latter part of the file name. For example `20080906120000_create_products.rb` should define `CreateProducts` and `20080906120001_add_details_to_products.rb` should define `AddDetailsToProducts`. If you do feel the need to change the file name then you MUST update the name of the class inside or Rails will complain about a missing class.
+Migrations are stored in files in `db/migrate`, one for each migration class. The name of the file is of the form `YYYYMMDDHHMMSS_create_products.rb`, that is to say a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration. The migration class' name must match (the camelcased version of) the latter part of the file name. For example `20080906120000_create_products.rb` should define CreateProducts and `20080906120001_add_details_to_products.rb` should define AddDetailsToProducts. If you do feel the need to change the file name then you MUST update the name of the class inside or Rails will complain about a missing class.
 
 Internally Rails only uses the migration's number (the timestamp) to identify them. Prior to Rails 2.1 the migration number started at 1 and was incremented each time a migration was generated. With multiple developers it was easy for these to clash requiring you to rollback migrations and renumber them. With Rails 2.1 this is largely avoided by using the creation time of the migration to identify them.
 
diff --git a/railties/doc/guides/migrations/rakeing_around.txt b/railties/doc/guides/migrations/rakeing_around.txt
index 9f927d079b..02fbecedb6 100644
--- a/railties/doc/guides/migrations/rakeing_around.txt
+++ b/railties/doc/guides/migrations/rakeing_around.txt
@@ -33,7 +33,7 @@ NOTE: this is not the same as running all the migrations - see the section on sc
 
 === Being Specific ===
 
-If you need to run a specific migration up or down the `db:migrate:up` and `db:migrate:down` tasks will do that. Just specify the appropriate `VERSION` and the corresponding migration will have its up or down method invoked, for example
+If you need to run a specific migration up or down the `db:migrate:up` and `db:migrate:down` tasks will do that. Just specify the appropriate version and the corresponding migration will have its up or down method invoked, for example
 
 `rake db:migrate:up VERSION=20080906120000`
 
diff --git a/railties/doc/guides/migrations/using_models_in_migrations.txt b/railties/doc/guides/migrations/using_models_in_migrations.txt
index eda216c50a..2a052e9207 100644
--- a/railties/doc/guides/migrations/using_models_in_migrations.txt
+++ b/railties/doc/guides/migrations/using_models_in_migrations.txt
@@ -19,7 +19,7 @@ class AddPartNumberToProducts < ActiveRecord::Migration
   end
 end
 -------------------------
-The migration has its own minimal copy of the `Product` model and no longer cares about the `Product` model defined in the application.
+The migration has its own minimal copy of the Product model and no longer cares about the Product model defined in the application.
 
 === Dealing with changing models ===
 
diff --git a/railties/doc/guides/migrations/writing_a_migration.txt b/railties/doc/guides/migrations/writing_a_migration.txt
index b04c41377b..e87838b0d2 100644
--- a/railties/doc/guides/migrations/writing_a_migration.txt
+++ b/railties/doc/guides/migrations/writing_a_migration.txt
@@ -154,6 +154,6 @@ class ExampleMigration < ActiveRecord::Migration
   end
 end
 ---------------------
-Sometimes your migration will do something which is just plain irreversible, for example it might destroy some data. In cases like those when you can't reverse the migration you can raise `IrreversibleMigration` from your down method. If someone tries to revert your migration an error message will be
+Sometimes your migration will do something which is just plain irreversible, for example it might destroy some data. In cases like those when you can't reverse the migration you can raise IrreversibleMigration from your down method. If someone tries to revert your migration an error message will be
 displayed saying that it can't be done.