diff --git a/README.ru b/README.ru
index d901ced..72c0b87 100644
--- a/README.ru
+++ b/README.ru
@@ -1,19 +1,25 @@
-Это фреймворк (не очень высокого уровня, на настоящий момент) для создания web-приложений на Haskell.
+Это фреймворк (не очень высокого уровня, на настоящий момент) для создания
+web-приложений на Haskell.
Состоит он из следующих частей:
* HTTP сервер (используется доработанный Network.Shed.Httpd)
* Модуль для работы с Cookies
- * Модуль для работы с пользовательскими сессиями (в настоящий момент, данные сессий хранятся в файлах, но можно написать другой backend)
+ * Модуль для работы с пользовательскими сессиями (в настоящий момент, данные
+ сессий хранятся в файлах, но можно написать другой backend)
* Модуль для кэширования чего угодно (бэкенды - filesystem, memcached и fake)
* URL dispatcher
- * Модуль для работы с БД (использует HDBC, в настоящий момент полноценно работает только с PostgreSQL, sqlite3 поддерживает не все запросы)
+ * Модуль для работы с БД (использует HDBC, в настоящий момент полноценно
+ работает только с PostgreSQL, sqlite3 поддерживает не все запросы)
* EDSL для описания моделей данных (таблиц БД)
* EDSL для формирования SQL-запросов по моделям данных
- * Templating Engine - шаблоны пишутся в отдельных файлах с синтаксисом a la Django, но при сборке приложения компилируются в результирующий бинарник
- * Подсистема обработки форм (генерация HTML формы по объекту, валидация форм, показ недозаполненной формы)
+ * Templating Engine - шаблоны пишутся в отдельных файлах с синтаксисом a la
+ Django, но при сборке приложения компилируются в результирующий бинарник
+ * Подсистема обработки форм (генерация HTML формы по объекту, валидация форм,
+ показ недозаполненной формы)
-Для соединения с БД используется пул соединений, тот же модуль используется для соединений с cache backend.
+Для соединения с БД используется пул соединений, тот же модуль используется для
+соединений с cache backend.
## Общие замечания об архитектуре
@@ -114,29 +120,60 @@ controller = do
## Сигналы
-Фреймворк включает модуль Signals, который работает в общих чертах аналогично сигналам в Django. Главное отличие -- сигналы и их обработчики регистрируются не во время исполнения, а статически.
+Фреймворк включает модуль Signals, который работает в общих чертах аналогично
+сигналам в Django. Главное отличие -- сигналы и их обработчики регистрируются
+не во время исполнения, а статически.
## Исключения
-Также фреймворк включает систему "исключений". Различаются два типа исключений: возникающие в контроллере (Controller exception) и возникающие на стадии обработки запроса (Request exception). Вторые порождает сам фреймворк -- например, когда не может найти подходящего контроллера для обработки URL. В контроллере можно породить исключение функцией raiseC с двумя параметрами -- код ошибки (соответствует HTTP status code) и собственно сообщение об ошибке.
+Также фреймворк включает систему "исключений". Различаются два типа исключений:
+возникающие в контроллере (Controller exception) и возникающие на стадии
+обработки запроса (Request exception). Вторые порождает сам фреймворк --
+например, когда не может найти подходящего контроллера для обработки URL. В
+контроллере можно породить исключение функцией raiseC с двумя параметрами --
+код ошибки (соответствует HTTP status code) и собственно сообщение об ошибке.
-По умолчанию работают простые встроенные обработчики исключений, но приложение может определить собственные (см. ниже).
+По умолчанию работают простые встроенные обработчики исключений, но приложение
+может определить собственные (см. ниже).
## Расширяемость
-Фреймворк является "точечно расширяемым". Это означает, что расширение функциональности фреймворка предусмотрено в некотором ограниченном количестве мест. Сейчас этими местами являются:
-
- * Генерация форм: приложение может определить функции, через которые будет проходить каждая форма (Form). Например, можно добавлять дополнительные поля итп.
- * Request Middlewares: это функции StaticConfig -> HttpRequest -> IO HttpRequest, через которые проходит каждый запрос прежде чем попасть в диспетчер URL.
- * Response Middlewares: это функции StaticConfig -> HttpResponse -> IO HttpResponse, через которые проходит ответ прежде чем он будет отдан веб-сервером.
- * Обработчики исключений: приложение может определить свои обработчики для request exceptions и controller exceptions.
-
-Все эти функции должны быть определены в приложении в модуле Settings.hs, оттуда их импортируют разные части фреймворка. В нём же определяется соответствие возможных сигналов и их обработчиков.
+Фреймворк является "точечно расширяемым". Это означает, что расширение
+функциональности фреймворка предусмотрено в некотором ограниченном количестве
+мест. Сейчас этими местами являются:
+
+ * Генерация форм: приложение может определить функции, через которые будет
+ проходить каждая форма (Form). Например, можно добавлять дополнительные поля
+ итп.
+ * Request Middlewares: это функции StaticConfig -> HttpRequest -> IO
+ HttpRequest, через которые проходит каждый запрос прежде чем попасть в
+ диспетчер URL.
+ * Response Middlewares: это функции StaticConfig -> HttpResponse -> IO
+ HttpResponse, через которые проходит ответ прежде чем он будет отдан
+ веб-сервером.
+ * Обработчики исключений: приложение может определить свои обработчики для
+ request exceptions и controller exceptions.
+
+Все эти функции должны быть определены в приложении в модуле Settings.hs,
+оттуда их импортируют разные части фреймворка. В нём же определяется
+соответствие возможных сигналов и их обработчиков.
## Интернационализация
-Для интернационализации используется gettext и его привязки к haskell - hgettext. В контроллерах для перевода строки следует использовать функцию __. Затем .hs файлы обрабатываются утилитой hgettext, получается messages.pot и т.д. как обычно с gettext. Интернационализация в шаблонах сейчас не предусмотрена, предлагается либо переводить строки в контроллерах, либо использовать разные шаблоны для разных языков.
-
-Встроенное middleware добавляет в каждый запрос два заголовка: X-UserLanguage и X-UserCharset, например X-UserLanguage: ru_RU, X-UserCharset: .UTF-8 (информация берётся из заголовков AcceptLanguage и AcceptEncoding). Эти заголовки можно использовать в приложении. Кроме того, другое встроенное middleware использует их для инициализации gettext. Таким образом, без усилий программиста приложения, с каждым пользователем оно будет разговаривать на его языке (том, который выставлен в браузере как язык по умолчанию). Если перевода на этот язык нет, будет использован английский.
+Для интернационализации используется gettext и его привязки к haskell -
+hgettext. В контроллерах для перевода строки следует использовать функцию __.
+Затем .hs файлы обрабатываются утилитой hgettext, получается messages.pot и
+т.д. как обычно с gettext. Интернационализация в шаблонах сейчас не
+предусмотрена, предлагается либо переводить строки в контроллерах, либо
+использовать разные шаблоны для разных языков.
+
+Встроенное middleware добавляет в каждый запрос два заголовка: X-UserLanguage и
+X-UserCharset, например X-UserLanguage: ru_RU, X-UserCharset: .UTF-8
+(информация берётся из заголовков AcceptLanguage и AcceptEncoding). Эти
+заголовки можно использовать в приложении. Кроме того, другое встроенное
+middleware использует их для инициализации gettext. Таким образом, без усилий
+программиста приложения, с каждым пользователем оно будет разговаривать на его
+языке (том, который выставлен в браузере как язык по умолчанию). Если перевода
+на этот язык нет, будет использован английский.
Сейчас фреймворк расчитан на использование кодировки UTF8.