19 июля 2011 Yuri Chornoivan написал:
> написане Tue, 19 Jul 2011 12:36:26 +0300, Андрей Черепанов
> 
> <cas@altlinux.ru>:
> > 19 июля 2011 Yuri Chornoivan написал:
> >> написане Tue, 19 Jul 2011 11:02:21 +0300, Андрей Черепанов
> >> 
> >> <cas@altlinux.ru>:
> >> > 19 июля 2011 Artem Sereda написал:
> >> >> Тем временем 15-го числа был стрингфриз грядущей версии KMyMoney,
> >> >> переводчики могут обновить переводы до 31 июля, 1 августа релиз.
> >> 
> >> 0. Выпуск перенесён на 8 августа. Документация будет изменена до 22 июля
> >> (добавлены пункты новинок в 4.6).
> >> 
> >> > Надо будет посмотреть. Но за то, что они не берут сделанные переводы
> >> 
> >> из
> >> 
> >> > SVN
> >> > для .desktop и не натягивают их на .desktop-файлы, я могу Юрию
> >> 
> >> Чорноивану
> >> 
> >> > сказать. что с этим технологически и дисциплинарно хреново в проекте
> >> 
> >> KDE.
> >> 
> >> 1. Что здесь не натянуто:
> >> 
> >> http://websvn.kde.org/trunk/extragear/office/kmymoney/kmymoney/kmymoney.
> >> des ktop?revision=1240780&view=markup
> >> 
> >> ?
> > 
> > Хм. Прошу прощения, в SVN самого KDE было изменение.
> > Интересно, почему переведённое 13 ноября 2010 и натянутое в SVN 14
> > ноября 2010
> > года, так и не попало в релиз
> > http://sourceforge.net/projects/kmymoney2/files/KMyMoney-KDE4/4.5.3/ 12
> > февраля 2011 года?
> 
> Это из-за расхлябанности разработчиков (или нежелания переходить на Git,
> как Вам угодно). Они не соизволили сообщить Альберту, что разработка
> стабильной версии ведётся в отдельной ветке. В результате полные переводы
> для версии в разработке оказались неполными для стабильной версии. С 4.6
> всё будет как у всех нормальных проектов с двумя ветвями разработки.
> 
> Ваш вариант с отдельным скриптом с треском провалится, как сейчас с
> треском проваливается подобная идея в Fedora (Transifex). Казалось бы,
> чудесная идея: достаточно отдать пару команд (tx pull и tx push) и всё в
> порядке. Переводы в пакете, репозиторий свободен от переводов (Canonical
> сосёт палец со своим пылесосом Rosetta). Но овраги помешали: разработчикам
> переводы совсем не интересны (большинство при формировании пакетов так и
> не удосуживается нажать заветные семь кнопок). Забавно, что этим страдают
> как раз разработчики самого Transifex (1.1 вышла в свет с неполным
> переводом, поскольку кто-то отдал команды tx push). Хорошие примеры
> (libvirt, libguestfs) с лихвой перекрываются печальным состоянием других
> (system-config-printer, packagekit, share-mime-info).
> 
> Все неавтоматические варианты ручной сборки, по моему скромному мнению,
> подтверждённому печальной практикой, заранее обречены. Все теории о
> поведении разработчиков с точки зрения переводчиков не больше, чем теории
> лучших физиков о поведении форели в ручье.
Для меня это не теория, а вопросы организации схемы локализации на 
l10n.lrn.ru/online. Сегодня думал написать в devel@lists.altlinux.org свои 
соображения.

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

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

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

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

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

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

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