Fixed #33842 -- Used :source: role for links to repo files on GitHub.

AUTHORS

@@ -799,6 +799,7 @@ answer newbie questions, and generally made Django that much better:
     Raffaele Salmaso <raffaele@salmaso.org>
     Rajesh Dhawan <rajesh.dhawan@gmail.com>
     Ramez Ashraf <ramezashraf@gmail.com>
+    Ramil Yanbulatov <rayman1104@gmail.com>
     Ramin Farajpour Cami <ramin.blackhat@gmail.com>
     Ramiro Morales <ramiro@rmorales.net>
     Ramon Saraiva <ramonsaraiva@gmail.com>

docs/howto/custom-model-fields.txt

@@ -724,7 +724,7 @@ serialization formats. Here are a couple of tips to make things go more
 smoothly:
 
 #. Look at the existing Django fields (in
-   :file:`django/db/models/fields/__init__.py`) for inspiration. Try to find
+   :source:`django/db/models/fields/__init__.py`) for inspiration. Try to find
    a field that's similar to what you want and extend it a little bit,
    instead of creating an entirely new field from scratch.
 
@@ -761,7 +761,7 @@ In addition to the above details, there are a few guidelines which can greatly
 improve the efficiency and readability of the field's code.
 
 #. The source for Django's own ``ImageField`` (in
-   ``django/db/models/fields/files.py``) is a great example of how to
+   :source:`django/db/models/fields/files.py`) is a great example of how to
    subclass ``FileField`` to support a particular type of file, as it
    incorporates all of the techniques described above.
 

docs/howto/custom-template-tags.txt

@@ -1153,5 +1153,5 @@ The only new concept here is the ``self.nodelist.render(context)`` in
 ``UpperNode.render()``.
 
 For more examples of complex rendering, see the source code of
-:ttag:`{% for %}<for>` in ``django/template/defaulttags.py`` and
+:ttag:`{% for %}<for>` in :source:`django/template/defaulttags.py` and
-:ttag:`{% if %}<if>` in ``django/template/smartif.py``.
+:ttag:`{% if %}<if>` in :source:`django/template/smartif.py`.

docs/howto/deployment/wsgi/modwsgi.txt

@@ -197,7 +197,7 @@ admin app (and any other installed apps). This is however not the case when you
 use any other server arrangement. You're responsible for setting up Apache, or
 whichever web server you're using, to serve the admin files.
 
-The admin files live in (:file:`django/contrib/admin/static/admin`) of the
+The admin files live in (:source:`django/contrib/admin/static/admin`) of the
 Django distribution.
 
 We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the

docs/internals/contributing/writing-code/javascript.txt

@@ -45,7 +45,7 @@ JavaScript tests
 ================
 
 Django's JavaScript tests can be run in a browser or from the command line.
-The tests are located in a top level ``js_tests`` directory.
+The tests are located in a top level :source:`js_tests` directory.
 
 Writing tests
 -------------
@@ -89,7 +89,7 @@ The JavaScript tests may be run from a web browser or from the command line.
 Testing from a web browser
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To run the tests from a web browser, open up ``js_tests/tests.html`` in your
+To run the tests from a web browser, open up :source:`js_tests/tests.html` in your
 browser.
 
 To measure code coverage when running the tests, you need to view that file

docs/internals/contributing/writing-code/submitting-patches.txt

@@ -303,6 +303,6 @@ All tickets
 * Is the pull request a single squashed commit with a message that follows our
   :ref:`commit message format <committing-guidelines>`?
 * Are you the patch author and a new contributor? Please add yourself to the
-  ``AUTHORS`` file and submit a `Contributor License Agreement`_.
+  :source:`AUTHORS` file and submit a `Contributor License Agreement`_.
 
 .. _Contributor License Agreement: https://www.djangoproject.com/foundation/cla/

docs/internals/contributing/writing-code/unit-tests.txt

@@ -379,9 +379,9 @@ and also excludes several directories not relevant to the results
 Contrib apps
 ============
 
-Tests for contrib apps can be found in the ``tests/`` directory, typically
+Tests for contrib apps can be found in the :source:`tests/` directory, typically
 under ``<app_name>_tests``. For example, tests for ``contrib.auth`` are located
-in ``tests/auth_tests``.
+in :source:`tests/auth_tests`.
 
 .. _troubleshooting-unit-tests:
 

docs/internals/contributing/writing-documentation.txt

@@ -23,7 +23,7 @@ Getting the raw documentation
 
 Though Django's documentation is intended to be read as HTML at
 https://docs.djangoproject.com/, we edit it as a collection of text files for
-maximum flexibility. These files live in the top-level ``docs/`` directory of a
+maximum flexibility. These files live in the top-level :source:`docs/` directory of a
 Django release.
 
 If you'd like to start contributing to our docs, get the development version of

docs/intro/tutorial07.txt

@@ -343,7 +343,7 @@ when loading Django templates; it's a search path.
 Now create a directory called ``admin`` inside ``templates``, and copy the
 template ``admin/base_site.html`` from within the default Django admin
 template directory in the source code of Django itself
-(``django/contrib/admin/templates``) into that directory.
+(:source:`django/contrib/admin/templates`) into that directory.
 
 .. admonition:: Where are the Django source files?
 

docs/ref/contrib/admin/index.txt

@@ -2591,8 +2591,8 @@ templates for a specific app, or a specific model.
 Set up your projects admin template directories
 -----------------------------------------------
 
-The admin template files are located in the ``contrib/admin/templates/admin``
+The admin template files are located in the
-directory.
+:source:`django/contrib/admin/templates/admin` directory.
 
 In order to override one or more of them, first create an ``admin`` directory
 in your project's ``templates`` directory. This can be any of the directories
@@ -2611,7 +2611,7 @@ directory, so make sure you name the directory in all lowercase if you are
 going to run your app on a case-sensitive filesystem.
 
 To override an admin template for a specific app, copy and edit the template
-from the ``django/contrib/admin/templates/admin`` directory, and save it to one
+from the :source:`django/contrib/admin/templates/admin` directory, and save it to one
 of the directories you just created.
 
 For example, if we wanted to add a tool to the change list view for all the
@@ -2729,10 +2729,10 @@ override to your project:
     {% endblock %}
 
 The list of CSS variables are defined at
-:file:`django/contrib/admin/static/admin/css/base.css`.
+:source:`django/contrib/admin/static/admin/css/base.css`.
 
 Dark mode variables, respecting the `prefers-color-scheme`_ media query, are
-defined at :file:`django/contrib/admin/static/admin/css/dark_mode.css`. This is
+defined at :source:`django/contrib/admin/static/admin/css/dark_mode.css`. This is
 linked to the document in ``{% block dark-mode-vars %}``.
 
 .. _prefers-color-scheme: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

docs/ref/contrib/index.txt

@@ -6,7 +6,7 @@ Django aims to follow Python's :ref:`"batteries included" philosophy
 <tut-batteries-included>`. It ships with a variety of extra, optional tools
 that solve common web development problems.
 
-This code lives in ``django/contrib`` in the Django distribution. This document
+This code lives in :source:`django/contrib` in the Django distribution. This document
 gives a rundown of the packages in ``contrib``, along with any dependencies
 those packages have.
 

docs/ref/django-admin.txt

@@ -2045,7 +2045,7 @@ Bash completion
 ---------------
 
 If you use the Bash shell, consider installing the Django bash completion
-script, which lives in ``extras/django_bash_completion`` in the Django source
+script, which lives in :source:`extras/django_bash_completion` in the Django source
 distribution. It enables tab-completion of ``django-admin`` and
 ``manage.py`` commands, so you can, for instance...
 

docs/ref/forms/renderers.txt

@@ -101,8 +101,8 @@ This renderer uses a standalone
 :class:`~django.template.backends.django.DjangoTemplates`
 engine (unconnected to what you might have configured in the
 :setting:`TEMPLATES` setting). It loads templates first from the built-in form
-templates directory in ``django/forms/templates`` and then from the installed
+templates directory in :source:`django/forms/templates` and then from the
-apps' templates directories using the :class:`app_directories
+installed apps' templates directories using the :class:`app_directories
 <django.template.loaders.app_directories.Loader>` loader.
 
 If you want to render templates with customizations from your
@@ -136,8 +136,8 @@ be removed at that time.
 
 This renderer is the same as the :class:`DjangoTemplates` renderer except that
 it uses a :class:`~django.template.backends.jinja2.Jinja2` backend. Templates
-for the built-in widgets are located in ``django/forms/jinja2`` and installed
+for the built-in widgets are located in :source:`django/forms/jinja2` and
-apps can provide templates in a ``jinja2`` directory.
+installed apps can provide templates in a ``jinja2`` directory.
 
 To use this backend, all the forms and widgets in your project and its
 third-party apps must have Jinja2 templates. Unless you provide your own Jinja2

docs/topics/cache.txt

@@ -438,7 +438,7 @@ cache backend with Django, use the Python import path as the
 
 If you're building your own backend, you can use the standard cache backends
 as reference implementations. You'll find the code in the
-``django/core/cache/backends/`` directory of the Django source.
+:source:`django/core/cache/backends/` directory of the Django source.
 
 Note: Without a really compelling reason, such as a host that doesn't support
 them, you should stick to the cache backends included with Django. They've

docs/topics/http/sessions.txt

@@ -526,7 +526,7 @@ calls ``save()`` and loops until an unused ``session_key`` is generated.
 
 If you're using the ``django.contrib.sessions.backends.db`` backend, each
 session is a normal Django model. The ``Session`` model is defined in
-``django/contrib/sessions/models.py``. Because it's a normal model, you can
+:source:`django/contrib/sessions/models.py`. Because it's a normal model, you can
 access sessions using the normal Django database API::
 
     >>> from django.contrib.sessions.models import Session

docs/topics/i18n/translation.txt

@@ -2080,7 +2080,7 @@ translations for the same literal:
 #. Then, it looks for and uses if it exists a ``locale`` directory in each
    of the installed apps listed in :setting:`INSTALLED_APPS`.  The ones
    appearing first have higher precedence than the ones appearing later.
-#. Finally, the Django-provided base translation in ``django/conf/locale``
+#. Finally, the Django-provided base translation in :source:`django/conf/locale`
    is used as a fallback.
 
 .. seealso::

docs/topics/settings.txt

@@ -90,7 +90,7 @@ Default settings
 
 A Django settings file doesn't have to define any settings if it doesn't need
 to. Each setting has a sensible default value. These defaults live in the
-module :file:`django/conf/global_settings.py`.
+module :source:`django/conf/global_settings.py`.
 
 Here's the algorithm Django uses in compiling settings: