Прошу обсудить вопросы организации схемы локализации на l10n.lrn.ru/online. 

Цель: обеспечить прозрачный контролируемый процесс локализации через веб-
интерфейс и возврат её в апстрим.

Есть проблема сопряжения усилий разработчиков и локализаторов. При этом в 
указанных схемах (Rosetta, Transifex) не был задействован QA, что и привело к 
закономерному бардаку и разрыву интересов разработчиков и локализаторов.

Вывод: с разработчиками нужно общаться только по крайней нужде, максимально 
уменьшив степень давления и требуемые телодвижения. Впрочем, это актуально и 
для локализаторов.

Предлагаю следующую схему:

1. На l10n.lrn.ru заводится отдельный git-репозиторий, в который клонируются 
по запросу) интересующие локализаторов репозитории или части сторонних VCS.
2. На каждый проект прописываются правила извлечения переводов (возможно, 
симлинки на первых порах) и обновление шаблонов (актуально для проектов 
GNOME/XFCE), а также интервал обновления репозитория.
3. Автоматически генерируются шаблоны, обновляются файлы переводов и 
имортируются в Narro.
4. Файлы локализации переводятся в Narro.
5. Переводы проверяются редактором и он же экспортирует переводы, что приводит 
к коммиту склонированных репозиториев.
6. Разработчики получают или уведомление с ссылкой на коммит или результат git 
format-patch (или патч/файл в ином виде). Если у редактора есть права на 
размещения в апстриме, он сам прикладывает коммит.

Преимущества подобной схемы:
а) бесшовная интеграция между VCS разработчиков и строками для локализаторов;
б) наличие ответственного за фиксацию переводов;
в) возможность простого наложения проверенного результата перевода;
г) снижение барьера для перевода без потери качества результата;
д) снижение требований к разработчикам по применению изменений;
е) прозрачный процесс контроля качества.

Прошу высказать замечания.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru