Deeper yofication of Russian translation (#251)

1 files changed, 3 insertions, 3 deletions

diff --git a/files/ru/web/api/service_worker_api/using_service_workers/index.html b/files/ru/web/api/service_worker_api/using_service_workers/index.html
index 4fc2235590..363d4331eb 100644
--- a/files/ru/web/api/service_worker_api/using_service_workers/index.html
+++ b/files/ru/web/api/service_worker_api/using_service_workers/index.html
@@ -13,7 +13,7 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers
 
 <h2 id="Предпосылки_появления_Service_Workers">Предпосылки появления Service Workers</h2>
 
-<p>Одной из важнейших проблем, от которой страдали пользователи веб-приложений, была работа в условиях потери связи. Лучшее в мире веб-приложение оставит ужасное впечатление от использования, если вы не сможете его загрузить. Предпринималось много попыток создания технологий, которые бы решили эту проблему, и если верить страницам нашего <a href="/en-US/Apps/Build/Offline">Форума</a>, некоторые из вопросов были решены. Но все же наиважнейшей проблемой по-прежнему является отсутствие хорошего механизма для управления кешем ресурсов и настраиваемыми сетевыми запросами.<br>
+<p>Одной из важнейших проблем, от которой страдали пользователи веб-приложений, была работа в условиях потери связи. Лучшее в мире веб-приложение оставит ужасное впечатление от использования, если вы не сможете его загрузить. Предпринималось много попыток создания технологий, которые бы решили эту проблему, и если верить страницам нашего <a href="/en-US/Apps/Build/Offline">Форума</a>, некоторые из вопросов были решены. Но всё же наиважнейшей проблемой по-прежнему является отсутствие хорошего механизма для управления кешем ресурсов и настраиваемыми сетевыми запросами.<br>
  <br>
  Предыдущей попыткой была технология AppCache, казавшаяся хорошей идеей, потому как позволяла действительно просто указывать ресурсы для кеширования. Однако, эта технология допускает много предположений о том, что вы пытаетесь сделать, и затем с грохотом ломается, когда ваше приложение работает не в точности с этими допущениями. Чтобы получить больше информации по этой теме, прочитайте (неудачно названную, но хорошо написанную) статью Джейка Арчибальда <a href="http://alistapart.com/article/application-cache-is-a-douchebag">Application Cache is a Douchebag</a>.</p>
 
@@ -83,7 +83,7 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers
 
 <p>В первом примере код, идущий за вызовом функции <code>myFunction()</code>, будет ждать завершения вызова и возврата значения. Во втором примере <code>myFunction()</code> возвращает промис для <code>value</code>, в этом случае, последующий код сможет выполняться, не дожидаясь завершения основной работы функции. Когда промис разрешится, код, переданный методу <code>then</code>, будет выполнен асинхронно.</p>
 
-<p>А вот вам реальный пример: что, если мы хотим загружать изображения динамически, к тому же мы желаем удостовериться, что изображения загрузились до того, как они будут показаны? То, что мы хотим сделать, является стандартной задачей, но она все же может доставить головной боли. Мы можем использовать <code>.onload</code>, чтобы показать изображение только после загрузки, но что делать с событиями, которые могут произойти до того, как мы начнём их слушать? Мы могли бы использовать <code>.complete</code>, но оно все ещё ненадёжно, да и что делать с повторяющимися изображениями? И наконец все это работает синхронно, блокируя главный поток.</p>
+<p>А вот вам реальный пример: что, если мы хотим загружать изображения динамически, к тому же мы желаем удостовериться, что изображения загрузились до того, как они будут показаны? То, что мы хотим сделать, является стандартной задачей, но она всё же может доставить головной боли. Мы можем использовать <code>.onload</code>, чтобы показать изображение только после загрузки, но что делать с событиями, которые могут произойти до того, как мы начнём их слушать? Мы могли бы использовать <code>.complete</code>, но оно все ещё ненадёжно, да и что делать с повторяющимися изображениями? И наконец все это работает синхронно, блокируя главный поток.</p>
 
 <p>Вместо этого мы можем написать собственный промис для работы с подобными случаями. (Вы можете найти исходный код в нашем примере <a href="https://github.com/mdn/promises-test">Promises test</a> или взглянуть на <a href="https://mdn.github.io/promises-test/">живое демо</a>.)</p>
 
@@ -177,7 +177,7 @@ imgLoad('myLittleVader.jpg').then((response) =&gt; {
  <li>Далее, чтобы зарегистрировать сервис-воркера для этого сайта, мы используем функцию {{domxref("ServiceWorkerContainer.register()") }}. Сервис-воркер представляет собой JavaScript-файл приложения (обратите внимание, что URL указывается относительно "корня", а не места расположения JS-файла, регистрирующего сервис-воркер).</li>
  <li>Параметр scope - не обязателен, он может быть использован для указания подмножества контента, которое вы хотите отдать под контроль сервис-воркера. В нашем случае, мы указали <code>'./sw-test/'</code>. Если вы не укажете его, то будет использовано значение по умолчанию; мы же указали его только в целях иллюстрации.</li>
  <li>Метод <code>.then()</code> был использован для обработки успешной регистрации. Если промис разрешится успешно, то код, переданный этому методу, будет выполнен.</li>
- <li>Ну и наконец, в конец нашего промиса мы добавляем функцию <code>.catch()</code>, которая будет выполнена в случае, если промис будет отклонен.</li>
+ <li>Ну и наконец, в конец нашего промиса мы добавляем функцию <code>.catch()</code>, которая будет выполнена в случае, если промис будет отклонён.</li>
 </ol>
 
 <p>Предыдущий код регистрирует сервис-воркера, который работает в worker-контексте, и следовательно, не имеет доступа к DOM. Затем вы запускаете код в сервис-воркере, вне ваших страниц, чтобы контролировать их загрузку.</p>