Так получилось, что основную массу переводов делаю сам, поэтому термины в голове. Контрибуторы, конечно, есть, но это, в основном, правка всяких стилистических / орфографических ошибок. Поэтому словарик понятий не составлен, хотя, конечно, был бы полезен, иногда термин приходится искать заново.
Синхронизация вручную, по принципу: «Вот появилось свободное время, давай-ка обновлю пару руководств до актуального состояния»
Вы можете при регистрации указать, что вас зовут Петя и вам 33 года, хотя вы Вася и вам 16 лет. Данные правильны, но не достоверны. Валидация тут не поможет. Поможет, к примеру, просьба выслать копию паспорта, заверенную нотариусом, но это же уже не валидация, а верификация.
С емейлом та же ситуация, подтверждение емейла — это не валидация, а аналог копии паспорта.
Валидация никогда не решала проблемы достоверности данных, а только правильности.
Причем, неправильность введенных данных может быть умышленной или случайной.
Поэтому очень странно звучит совет проверить возможную случайную ошибку средством проверки достоверности (отправкой и подтверждением мейла), когда можно обойтись банальной валидацией.
Как раз версия тут кое-что значит — они стандартизировали набор полей, к которой сводится получаемая от провайдера информация — теперь можно писать универсальные методы для нескольких провайдеров сразу.
Про attr_protected еще в гайде по безопасности для 2.3 писали, что не стоит его использовать (правда, по другой причине). Так что, кто не спрятался — тот сам виноват.
Учебник замечательный, читал в оригинале (на сайте Стэнфордского университета нашел электронный экземпляр в свободном доступе).
Насчет псевдокода — лучше его оставить в полностью неизменном виде, русский текст его только портит. Переводить следует только пояснения (ну и возможно добавить свои, от переводчика)
where(["id not in (?)", checked.pluck(:id)])упрощается до
where.not(id: checked.ids)Не думал, что скачиваемый pdf популярен, немного пристыдился, на сайте гораздо свежее переводы… Нужно бы сверстать pdf поновее :)
Синхронизация вручную, по принципу: «Вот появилось свободное время, давай-ка обновлю пару руководств до актуального состояния»
Фреймворк развивается, документация дописывается. Статичные тексты смысла нет переводить, если их не поддерживать в актуальном состоянии после.
Я проблему решил так: есть репозиторий с руководствами: github.com/lifo/docrails/tree/master/guides/source. Есть мой репозиторий с переводами: github.com/morsbox/rusrails/tree/master/source. Есть файл-манифест, в котором текущая версия перевода привязывается к определенной ревизии оригинала: github.com/morsbox/rusrails/blob/master/source/pages.yml
Чтобы актуализировать перевод — достаточно взять дифф ревизий текущей и актуальной версии, перевести его, и обновить файл манифеста.
Для вашей документации тоже есть репозиторий, насколько я вижу ( github.com/angular/angular.js/tree/master/docs/content/guide ) — так что подобная методика вполне подойдет.
Verification Action — это разновидность Post-validation actions. То есть к валидации имеет лишь косвенное отношение.
С емейлом та же ситуация, подтверждение емейла — это не валидация, а аналог копии паспорта.
Причем, неправильность введенных данных может быть умышленной или случайной.
Поэтому очень странно звучит совет проверить возможную случайную ошибку средством проверки достоверности (отправкой и подтверждением мейла), когда можно обойтись банальной валидацией.
Отправка письма с подтверждением — потеря определенной доли посетителей.
Насчет псевдокода — лучше его оставить в полностью неизменном виде, русский текст его только портит. Переводить следует только пояснения (ну и возможно добавить свои, от переводчика)