1 files changed, 6 insertions, 6 deletions
diff --git a/files/ru/learn/server-side/django/introduction/index.html b/files/ru/learn/server-side/django/introduction/index.html
index f2f6b957f7..94584856c9 100644
--- a/files/ru/learn/server-side/django/introduction/index.html
+++ b/files/ru/learn/server-side/django/introduction/index.html
@@ -61,7 +61,7 @@ original_slug: Learn/Server-side/Django/Введение
 <p>Django продолжает расти и улучшаться с момента его первого релиза (1.0) в сентябре 2008 года до недавно выпущенной версии 3.1 (2020). В каждой версии добавлены новые функциональные возможности и исправлены ошибки, начиная от поддержки новых типов баз данных, шаблонизаторов и кэширования, до добавления «общих» функций просмотра и классов (уменьшающих объём кода, который разработчики должны писать для ряда программных задач).</p>
 
 <div class="note">
-<p><strong>Заметка</strong>: Ознакомтесь с <a href="https://docs.djangoproject.com/en/3.1/releases/">примечаниями к версии</a> на сайте <span style="line-height: 1.5;">Django, чтобы увидеть что изменилось в последних версиях и как много работы было проделано, чтобы улучшить Django.</span></p>
+<p><strong>Заметка</strong>: Ознакомьтесь с <a href="https://docs.djangoproject.com/en/3.1/releases/">примечаниями к версии</a> на сайте <span style="line-height: 1.5;">Django, чтобы увидеть что изменилось в последних версиях и как много работы было проделано, чтобы улучшить Django.</span></p>
 </div>
 
 <p>Django — это процветающий совместный проект с открытым исходным кодом, в котором заняты многие тысячи пользователей и участников. Несмотря на то, что у него всё ещё есть некоторые особенности, которые отражают его происхождение, Django превратился в универсальный фреймворк, способный разрабатывать веб-сайты любого типа.</p>
@@ -76,7 +76,7 @@ original_slug: Learn/Server-side/Django/Введение
 
 <h2 id="Является_ли_Django_гибким">Является ли Django гибким?</h2>
 
-<p>Веб-фрейморки часто можно поделить на "гибкие" и "негибкие".</p>
+<p>Веб-фреймворки часто можно поделить на "гибкие" и "негибкие".</p>
 
 <p>Негибкие - это те, у которых есть "правильный путь" для решения какой-либо конкретной задачи. Они часто поддерживают быстрое развёртывание в <em>определенной области</em> (решение проблем определенного типа), потому что правильный способ сделать что-либо обычно хорошо понимается и хорошо документируется. Однако они могут быть менее гибкими при решении проблем за пределами их основной сферы и, как правило, предлагают меньше вариантов того, какие компоненты и подходы они могут использовать.</p>
 
@@ -86,7 +86,7 @@ original_slug: Learn/Server-side/Django/Введение
 
 <h2 id="Как_выглядит_код_Django">Как выглядит код Django?</h2>
 
-<p>На традиционном информационом веб-сайте веб-приложение ожидает HTTP-запросы от веб-браузера (или другого клиента). Когда запрос получен, приложение разрабатывает то, что необходимо на основе URL-адреса и, возможно, данных в <code>POST</code> или <code>GET</code> запросах. В зависимости от того, что требуется, далее он может читать или записывать информацию из базы данных или выполнять другие задачи, необходимые для удовлетворения запроса. Затем приложение вернёт ответ веб-браузеру, часто динамически создавая HTML-страницу для отображения в браузере, вставляя полученные данные в HTML-шаблон.</p>
+<p>На традиционном информационном веб-сайте веб-приложение ожидает HTTP-запросы от веб-браузера (или другого клиента). Когда запрос получен, приложение разрабатывает то, что необходимо на основе URL-адреса и, возможно, данных в <code>POST</code> или <code>GET</code> запросах. В зависимости от того, что требуется, далее он может читать или записывать информацию из базы данных или выполнять другие задачи, необходимые для удовлетворения запроса. Затем приложение вернёт ответ веб-браузеру, часто динамически создавая HTML-страницу для отображения в браузере, вставляя полученные данные в HTML-шаблон.</p>
 
 <p>Веб-приложения, написанные на Django, обычно группируют код, который обрабатывает каждый из этих шагов, в отдельные файлы:</p>
 
@@ -110,7 +110,7 @@ original_slug: Learn/Server-side/Django/Введение
 
 <h3 id="Отправка_запроса_в_правильное_view_urls.py">Отправка запроса в правильное view (urls.py)</h3>
 
-<p>Сопоставитель URL-адресов обычно содержится в файле <strong>urls.py</strong>. В примере ниже сопоставитель (<code>urlpatterns</code>) определяет список сопоставлений между<em>маршрутами </em>(определёнными URL-<em>шаблонами</em>) и соотвествующими функциями отображения (view). Если получен HTTP-запрос, который имеет URL-адрес, соответствующий определённому шаблону, то затем будет вызвана связанная функция отображения (view) и передана в запрос.</p>
+<p>Сопоставитель URL-адресов обычно содержится в файле <strong>urls.py</strong>. В примере ниже сопоставитель (<code>urlpatterns</code>) определяет список сопоставлений между<em>маршрутами </em>(определёнными URL-<em>шаблонами</em>) и соответствующими функциями отображения (view). Если получен HTTP-запрос, который имеет URL-адрес, соответствующий определённому шаблону, то затем будет вызвана связанная функция отображения (view) и передана в запрос.</p>
 
 <pre class="notranslate">urlpatterns = [
     <strong>path('admin/', admin.site.urls),
@@ -158,7 +158,7 @@ def index(request):
 
 <h3 id="Определение_данных_модели_models.py">Определение данных модели (models.py)</h3>
 
-<p>Веб-приложения Django обрабатывают и запрашивают данные через объекты Python, называемые моделями. Модели определяют структуру хранимых данных, включая типы полей и, возможно, их максимальный размер, значения по умолчанию, параметры списка выбора, текст справки для документации, текст меток для форм и т. д. Определение модели не зависит от используемой базы данных — ваши модели будут работать в любой из них. После того как вы выбрали базу данных, которую хотите использовать, вам не нужно напрямую обращатся к ней — вы просто пишете свою структуру модели и другой код, а Django выполняет всю «грязную работу» по обращению к базе данных за вас.</p>
+<p>Веб-приложения Django обрабатывают и запрашивают данные через объекты Python, называемые моделями. Модели определяют структуру хранимых данных, включая типы полей и, возможно, их максимальный размер, значения по умолчанию, параметры списка выбора, текст справки для документации, текст меток для форм и т. д. Определение модели не зависит от используемой базы данных — ваши модели будут работать в любой из них. После того как вы выбрали базу данных, которую хотите использовать, вам не нужно напрямую обращаться к ней — вы просто пишете свою структуру модели и другой код, а Django выполняет всю «грязную работу» по обращению к базе данных за вас.</p>
 
 <p>В приведённом ниже фрагменте кода показана очень простая модель Django для объекта <code>Team</code>. Класс <code>Team</code> наследуется от класса <code>models.Model</code>. Он определяет имя команды и командный уровень в качестве полей символов и задаёт максимальное количество символов, которые могут быть сохранены для каждой записи. <code>Team_level</code> может быть одним из нескольких значений, поэтому мы определяем его как поле выбора и предоставляем сопоставление между отображаемыми вариантами и хранимыми данными вместе со значением по умолчанию.</p>
 
@@ -192,7 +192,7 @@ class Team(models.Model):
 
 <p>Модель Django предоставляет простой API запросов для поиска в базе данных. Поиск может осуществляться по нескольким полям одновременно, используя различные критерии (такие как exact («точный»), case-insensitive («без учёта регистра»), greater than («больше чем») и т. д.), и может поддерживать сложные выражения (например, вы можете указать поиск в командах U11, у которых есть имя команды, начинающееся с «Fr» или заканчивается на «al»).</p>
 
-<p>Фрагмент кода показывает функцию view (обработчик ресурсов) для отображения всех команд U09. Выделенная жирным строка показывет, как мы можем использовать модель API-запросов для того, чтобы отфильтровать все записи, где поле <code>team_level</code> в точности содержит текст 'U09' (обратите внимание, как эти критерии передаются функции <code>filter()</code> в качестве аргумента с именем поля и типом соответствия, разделённым двойным подчеркиванием: <strong>team_level__exact</strong>). </p>
+<p>Фрагмент кода показывает функцию view (обработчик ресурсов) для отображения всех команд U09. Выделенная жирным строка показывает, как мы можем использовать модель API-запросов для того, чтобы отфильтровать все записи, где поле <code>team_level</code> в точности содержит текст 'U09' (обратите внимание, как эти критерии передаются функции <code>filter()</code> в качестве аргумента с именем поля и типом соответствия, разделённым двойным подчеркиванием: <strong>team_level__exact</strong>). </p>
 
 <pre class="brush: python notranslate">## filename: views.py