Re: [kde-russian] Трекер задач на Phabricator

[Alexander Potashev <aspotashev@gmail.com>]

вс, 19 мая 2019 г. в 01:29, Mikhail Novosyolov <m.novosyolov@rosalinux.ru>:
>
> 18.05.2019 16:55, Alexander Potashev пишет:
> > сб, 18 мая 2019 г. в 15:46, Mikhail Novosyolov <m.novosyolov@rosalinux.ru>:
> >> 18.05.2019 15:25, Alexander Potashev пишет:
> >>> Думаю, туда удобно складывать любые задачи,
> >>> выходящие за рамки локализации приложений.
> >> А входящие в рамки локализации приложений?
> > Сейчас такого трекера нет.
> Собираюсь заняться переводом kdenlive, но есть опасения, что одна и та
> же работа окажется сделана разными людьми одновременно. Было бы неплохо
> иметь какое-то представление о том, чем занимается хотя бы часть других
> людей. Наверняка мои опасения преувеличены, т.к. таких людей мало.
> > Есть внутренний Git, которым я и Саша Яворский пользуемся для удобства
> > рецензирования. Поиском по этому репозиторию, по почтовому ящику и по
> > Telegram я могу понять, есть ли готовые переводы для конкретного
> > приложения, которые ещё не попали в SVN. Если очень любопытно, могу
> > дать доступ на чтение, для этого нужен аккаунт на
> > https://bitbucket.org
> >
> > Теоретически можно для переводов использовать подобную доску, но на
> > мой взгляд это создаст волокиту (на каждый перевод придётся создавать
> > задачу, а потом её закрывать), а польза неочевидна. Можно приспособить
> > баг-трекер bugs.kde.org: заставить переводчиков создавать тикет и
> > прикреплять к нему перевод, но это создаст дополнительный барьер для
> > переводчиков.
>
> Как я понял, переводчики не горят желанием пользоваться git и пр., им
> понятнее просто пересылать друг другу файлы. В результате я был вынужден
> в RPM-спеке комментарием оставить ссылку на присланный языковой файл на
> Яндекс-диске, чтобы при необходимости можно было хоть как-то понять,
> откуда перевод и каковы его взаимоотношения с другими имеющимися
> переводами. Это несколько странно.
>
> Про волокиту согласен.
>
> Я не переводчик и могу не знать нюансов, но не вижу большой проблемы
> совместно работать нескольким людям над одним переводом в git. Что-то
> вроде песочницы, где перевод варится перед отправкой в svn. У
> большинства приложений в таком git необходимости нет и не будет, но есть
> ряд приложений, переводом которых время от времени занимается несколько
> людей (плюс возможны пулл-реквесты от других), там песочница с
> совместным доступом будет иметь смысл. Главное при разногласиях не
> разругаться, чей вариант перевода оставить.

Привет,

Объявите в отдельном письме о том, что Вы начали обновлять перевод
Kdenlive. Если есть другие желающие помочь или люди, уже начавшие тихо
переводить, она скорее всего откликнутся. Для пущей надёжности можете
спросить людей, которые переводили Kdenlive в прошлом.

Чаще всего я не знаю, кто чем занимается, потом внезапно кто-нибудь
присылает готовый перевод на тысячи строк. Для мелких файлов ничего
страшного, т.к. период времени, пока человек переводит, короткий, и
маловероятно, что за это время кто-то ещё начнёт переводить. Даже если
есть два предложенных новых перевода, конфликты легко разрулить в
Lokalize, если файл не огромный. Либо можно последовательно
отрецензировать оба варианта.

То есть Вы предлагаете положить kdenlive.po в Git и позволить
нескольким людям его редактировать? Подозреваю, что возникнут проблемы
с случае конфликтов версий: их будет намного сложнее разрешить, чем в
ситуации с конфликтующими правками исходного кода. Стандартные
пулл-реквесты практически невозможны, потому что патч, созданный
сегодня, на следующий день может не наложиться на свежую версию
kdenlive.po из SVN.

Возможно, всё будет хорошо, если разрешить работать с переводом в Git
только по очереди. Но тогда и Git не нужен: в ситуации, когда надо
срочно доперевести программу, команда по переводу Kdenlive может
сделать себе чат в удобном мессенджере и договориться, кто в какие дни
будет переводить. Каждая новая версия перевода отправляется обратно в
чат, чтобы её подхватил следующий участник этой эстафеты.

-- 
Alexander Potashev