Changed convention for modules storing AppConfigs.

The app/apps dichotomy was more confusing than valuable.

1 files changed, 4 insertions, 4 deletions

diff --git a/docs/ref/applications.txt b/docs/ref/applications.txt
index ed3f33a2cc..0713da76ed 100644
--- a/docs/ref/applications.txt
+++ b/docs/ref/applications.txt
@@ -59,7 +59,7 @@ For application authors
 If you're creating a pluggable app called "Rock ’n’ roll", here's how you
 would provide a proper name for the admin::
 
-    # rock_n_roll/app.py
+    # rock_n_roll/apps.py
 
     from django.apps import AppConfig
 
@@ -67,11 +67,11 @@ would provide a proper name for the admin::
         name = 'rock_n_roll'
         verbose_name = "Rock ’n’ roll"
 
-You would then tell your users to add ``'rock_n_roll.app.RockNRollConfig'`` to
-their :setting:`INSTALLED_APPS`.
+You would then tell your users to add ``'rock_n_roll.apps.RockNRollConfig'``
+to their :setting:`INSTALLED_APPS`.
 
 The recommended convention is to put the configuration class in a submodule of
-the application called ``app``. However, this isn't enforced by Django.
+the application called ``apps``. However, this isn't enforced by Django.
 
 You must include the :attr:`~django.apps.AppConfig.name` attribute for Django
 to determine which application this configuration applies to. You can define