Merge pull request #80 from jpineda1/jpineda1/update-russian-translation

fixed russian translation

app/views/ru/glossary.scala.html

@@ -30,7 +30,7 @@ <h2 id="Asynchronous"><a href="#Asynchronous" class="link-icon">@image("link-ico
 <p>Слово «асинхронный» означает «не совпадающий с чем-либо во времени; неодномоментный, неодновременный» и характеризует процессы, не совпадающие во времени. В контексте данного манифеста под этим словом подразумевается, что обработка запроса, переданного от клиента к сервису, выполняется в произвольные моменты времени. Клиент не может напрямую следить за выполнением внутри сервиса и синхронизироваться с ним. Это противоположность синхронной обработки, при которой клиент возобновляет собственную работу только после того, как сервис обработает запрос.</p>
 
 <h2 id="Back-Pressure"><a href="#Back-Pressure" class="link-icon">@image("link-icon.png")</a>Обратное давление</h2>
-<p>Когда один <a href="#Component">компонент</a> перегружен запросами, <a href="#System">система</a> в целом должна на это разумно отреагировать. Нельзя допустить, чтобы нагруженный компонент полностью вышел из строя или начал отклонять произвольные сообщения. Так как компонент перегружен и не может отказать в обслуживании ему следует сообщить о своем состоянии компонентам более высокого уровня, чтобы те снизили нагрузку. Обратное давление является важным механизмом обратной связи, с помощью которого система может адекватно отреагировать на нагрузку вместо того, чтобы обрушиться. Обратное давление может передаваться вверх по иерархии вплоть до самого пользователя. В этом случае может пострадать доступность, но взамен мы получим гарантию того, что система останется устойчивой и предоставит информацию, которая даст возможность ей выделить дополнительные ресурсы и распределить нагрузку (см. «<a href="#Elasticity">Гибкость</a>»).</p>
+<p>Когда один <a href="#Component">компонент</a> перегружен запросами, <a href="#System">система</a> в целом должна на это разумно отреагировать. Нельзя допустить, чтобы нагруженный компонент полностью вышел из строя или начал отклонять произвольные сообщения. Так как компонент перегружен и не может отказать в обслуживании ему следует сообщить о своем состоянии компонентам более высокого уровня, чтобы те снизили нагрузку. Обратное давление является важным механизмом обратной связи, с помощью которого система может адекватно отреагировать на нагрузку вместо того, чтобы обрушиться. Обратное давление может передаваться вверх по иерархии вплоть до самого пользователя. В этом случае может пострадать отзывчивость, но взамен мы получим гарантию того, что система останется устойчивой и предоставит информацию, которая даст возможность ей выделить дополнительные ресурсы и распределить нагрузку (см. «<a href="#Elasticity">Гибкость</a>»).</p>
 
 <h2 id="Batching"><a href="#Batching" class="link-icon">@image("link-icon.png")</a>Пакетирование</h2>
 <p>Современные компьютеры оптимизированы для многократного выполнения одной и той же задачи: кэширование инструкций и предсказание ветвлений повышают скорость вычислений при неизменной тактовой частоте. Это означает, что последовательное выполнение множества разных действий на одном и том же ядре процессора не позволит добиться максимальной производительности: по возможности программу следует структурировать так, чтобы она реже переключалась между разными задачами. Это может быть как пакетная обработка данных, так и выполнение разных этапов вычисления в отдельных аппаратных потоках.</p>

app/views/ru/manifesto.scala.html

@@ -6,21 +6,20 @@
 <section id="the-reactive-manifesto">
     <p>Организации, работающие в совершенно разных отраслях, независимо друг от друга находят для себя похожие шаблоны создания программного обеспечения. Основанные на них системы оказываются более надежными, устойчивыми, гибкими и соответствующими современным требованиям.</p>
     <p>В последние годы требования к приложениям кардинально изменились. Всего несколько лет назад большим считалось приложение, состоящее из десятков серверов, тогда время ответа измерялось секундами, простои при техническом обслуживании - часами, а данные для обработки - гигабайтами. Сегодня приложения устанавливаются на всем, от мобильных устройств до облачных кластеров, насчитывающих тысячи многоядерных процессоров. Пользователи привыкли к миллисекундным задержкам и стопроцентной доступности, а данные тем временем измеряются петабайтами. Программные архитектуры вчерашнего дня не способны удовлетворить требованиям дня сегодняшнего.</p>
-    <p>Мы считаем, что для проектирования приложений необходим четкий и понятный подход, и что все его отдельные аспекты уже сформулированы: мы хотим, чтобы система была доступной, устойчивой, гибкой и основанной на обмене сообщениями. Мы называем такие системы Реактивными.</p>
-    <p>Приложения, написанные в соответствии с принципами Реактивных Систем, отличаются повышенной гибкостью, <a href="/ru/glossary#Scalability">масштабируемостью</a> и слабой связанностью. Благодаря этому их проще разрабатывать и модифицировать. Они более устойчивы к <a href="/ru/glossary#Failure">отказам</a> и корректно обрабатывают исключительные ситуации, избегая катастрофических последствий. Реактивные системы характеризуются высокой доступностью, обеспечивая <a href="/ru/glossary#User">пользователям</a> эффективную и интерактивную обратную связь.</p>
+    <p>Мы считаем, что для проектирования приложений необходим четкий и понятный подход, и что все его отдельные аспекты уже сформулированы: мы хотим, чтобы система была отзывчивой, устойчивой, гибкой и основанной на обмене сообщениями. Мы называем такие системы Реактивными.</p>
+    <p>Приложения, написанные в соответствии с принципами Реактивных Систем, отличаются повышенной гибкостью, <a href="/ru/glossary#Scalability">масштабируемостью</a> и слабой связанностью. Благодаря этому их проще разрабатывать и модифицировать. Они более устойчивы к <a href="/ru/glossary#Failure">отказам</a> и корректно обрабатывают исключительные ситуации, избегая катастрофических последствий. Реактивные системы характеризуются высокой отзывчивостью, обеспечивая <a href="/ru/glossary#User">пользователям</a> эффективную и интерактивную обратную связь.</p>
     <h3>Реактивные Системы:</h3>
 </section>
-
 <section id="responsive" class="trait">
-    <p><strong>Доступные:</strong> <a href="/ru/glossary#System">Система</a> отвечает своевременно, если это вообще возможно. Доступность является краеугольным камнем удобного и полезного приложения, но, помимо этого, она позволяет быстро обнаруживать проблемы и эффективно их устранять. Доступные системы ориентированы на обеспечение быстрого и согласованного времени отклика, устанавливая надежные верхние границы, чтобы обеспечить стабильное качество обслуживания. Такое предсказуемое поведение, в свою очередь, упрощает обработку ошибок, повышает уверенность конечного пользователя в работоспособности и способствует дальнейшему взаимодействию с системой.</p>
+    <p><strong>Отзывчивые:</strong> <a href="/ru/glossary#System">Система</a> отвечает своевременно, если это вообще возможно. Отзывчивость является краеугольным камнем удобного и полезного приложения, но, помимо этого, она позволяет быстро обнаруживать проблемы и эффективно их устранять. Отзывчивые системы ориентированы на обеспечение быстрого и согласованного времени отклика, устанавливая надежные верхние границы, чтобы обеспечить стабильное качество обслуживания. Такое предсказуемое поведение, в свою очередь, упрощает обработку ошибок, повышает уверенность конечного пользователя в работоспособности и способствует дальнейшему взаимодействию с системой.</p>
 </section>
 
 <section id="resilient" class="trait">
-    <p><strong>Устойчивые:</strong> Система остается доступной даже в случае <a href="/ru/glossary#Failure">отказов</a>. Это относится не только к высокодоступным, критически важным приложениям — без устойчивости любая система при сбое теряет доступность. Устойчивость достигается за счет <a href="/ru/glossary#Replication"> репликации</a>, сдерживания, <a href="/ru/glossary#Isolation">изоляции</a> и <a href="/ru/glossary#Delegation">делегирования</a>. Эффект от отказов удерживаeтся внутри <a href="/ru/glossary#Component">компонентов</a>, изолируя их друг от друга, что позволяет им выходить из строя и восстанавливаться, не нарушая работу системы в целом. Восстановление каждого компонента делегируется другому (внешнему) модулю, а высокая доступность обеспечивается за счет репликации там, где это необходимо. Клиент компонента не отвечает за обработку его сбоев.</p>
+    <p><strong>Устойчивые:</strong> Система остается доступной даже в случае <a href="/ru/glossary#Failure">отказов</a>. Это относится не только к высокодоступным, критически важным приложениям — без устойчивости любая система при сбое теряет отзывчивость. Устойчивость достигается за счет <a href="/ru/glossary#Replication"> репликации</a>, сдерживания, <a href="/ru/glossary#Isolation">изоляции</a> и <a href="/ru/glossary#Delegation">делегирования</a>. Эффект от отказов удерживаeтся внутри <a href="/ru/glossary#Component">компонентов</a>, изолируя их друг от друга, что позволяет им выходить из строя и восстанавливаться, не нарушая работу системы в целом. Восстановление каждого компонента делегируется другому (внешнему) модулю, а высокая доступность обеспечивается за счет репликации там, где это необходимо. Клиент компонента не отвечает за обработку его сбоев.</p>
 </section>
 
 <section id="elastic" class="trait">
-   <p><strong>Гибкие:</strong> Система остается доступной под разными нагрузками. Реактивные Системы способны реагировать на колебания в скорости входящих потоков, увеличивая или уменьшая количество выделенных на их обслуживание <a href="/ru/glossary#Resource">ресурсов</a>. Для этого архитектура не должна допускать наличия централизованных узких мест или конкуренции за ресурсы, что позволяет сегментировать или реплицировать компоненты, распределяя между ними входные данные. Реактивные Системы поддерживают предсказывающие и Реактивные алгоритмы масштабирования, позволяя делать измерения производительности в режиме реального времени. <a href="/ru/glossary#Elasticity">Гибкость</a> достигается применением экономически эффективных аппаратных и программных платформ.</p>
+   <p><strong>Гибкие:</strong> Система остается отзывчивой под разными нагрузками. Реактивные Системы способны реагировать на колебания в скорости входящих потоков, увеличивая или уменьшая количество выделенных на их обслуживание <a href="/ru/glossary#Resource">ресурсов</a>. Для этого архитектура не должна допускать наличия централизованных узких мест или конкуренции за ресурсы, что позволяет сегментировать или реплицировать компоненты, распределяя между ними входные данные. Реактивные Системы поддерживают предсказывающие и  Реактивные алгоритмы масштабирования, позволяя делать измерения производительности в режиме реального времени. <a href="/ru/glossary#Elasticity">Гибкость</a> достигается применением экономически эффективных аппаратных и программных платформ.</p>
 </section>
 
 <section id="message-driven" class="trait">