Removed code terms from docs/spelling_wordlist.

docs/topics/i18n/translation.txt

@@ -663,7 +663,7 @@ You can use multiple expressions inside a single ``blocktrans`` tag::
 Other block tags (for example ``{% for %}`` or ``{% if %}``) are not allowed
 inside a ``blocktrans`` tag.
 
-If resolving one of the block arguments fails, blocktrans will fall back to
+If resolving one of the block arguments fails, ``blocktrans`` will fall back to
 the default language by deactivating the currently active language
 temporarily with the :func:`~django.utils.translation.deactivate_all`
 function.
@@ -1525,7 +1525,7 @@ multiple times::
 
     When :ref:`creating message files from JavaScript source code
     <creating-message-files-from-js-code>` you need to use the special
-    'djangojs' domain, **not** ``-e js``.
+    ``djangojs`` domain, **not** ``-e js``.
 
 .. admonition:: Using Jinja2 templates?
 
@@ -1876,7 +1876,7 @@ For example::
             translation.activate(cur_language)
         return text
 
-Calling this function with the value 'de' will give you ``"Willkommen"``,
+Calling this function with the value ``'de'`` will give you ``"Willkommen"``,
 regardless of :setting:`LANGUAGE_CODE` and language set by middleware.
 
 Functions of particular interest are
@@ -2023,8 +2023,8 @@ Notes:
       ]
 
   This example restricts languages that are available for automatic
-  selection to German and English (and any sublanguage, like de-ch or
-  en-us).
+  selection to German and English (and any sublanguage, like ``de-ch`` or
+  ``en-us``).
 
 * If you define a custom :setting:`LANGUAGES` setting, as explained in the
   previous bullet, you can mark the language names as translation strings

docs/topics/migrations.txt

@@ -627,9 +627,10 @@ or with a ``CircularDependencyError``, in which case you can manually resolve it
 To manually resolve a ``CircularDependencyError``, break out one of
 the ForeignKeys in the circular dependency loop into a separate
 migration, and move the dependency on the other app with it. If you're unsure,
-see how makemigrations deals with the problem when asked to create brand
-new migrations from your models. In a future release of Django, squashmigrations
-will be updated to attempt to resolve these errors itself.
+see how :djadmin:`makemigrations` deals with the problem when asked to create
+brand new migrations from your models. In a future release of Django,
+:djadmin:`squashmigrations` will be updated to attempt to resolve these errors
+itself.
 
 Once you've squashed your migration, you should then commit it alongside the
 migrations it replaces and distribute this change to all running instances

docs/topics/serialization.txt

@@ -180,7 +180,7 @@ The basic XML serialization format is quite simple::
         </object>
     </django-objects>
 
-The whole collection of objects that is either serialized or de-serialized is
+The whole collection of objects that is either serialized or deserialized is
 represented by a ``<django-objects>``-tag which contains multiple
 ``<object>``-elements. Each such object has two attributes: "pk" and "model",
 the latter being represented by the name of the app ("sessions") and the
@@ -198,11 +198,11 @@ Foreign keys and other relational fields are treated a little bit differently::
         <!-- ... -->
     </object>
 
-In this example we specify that the auth.Permission object with the PK 27 has
-a foreign key to the contenttypes.ContentType instance with the PK 9.
+In this example we specify that the ``auth.Permission`` object with the PK 27
+has a foreign key to the ``contenttypes.ContentType`` instance with the PK 9.
 
 ManyToMany-relations are exported for the model that binds them. For instance,
-the auth.User model has such a relation to the auth.Permission model::
+the ``auth.User`` model has such a relation to the ``auth.Permission`` model::
 
     <object pk="1" model="auth.user">
         <!-- ... -->