Midnight Commander: белоруский перевод.

[slavaz]

Господа, прошу помощи с переводами.

Прямая ссылка для be.po : http://www.midnight-commander.org/expor ... 3/po/be.po

Результат приаттачьте к этому тикету:
http://www.midnight-commander.org/ticket/1370

Или мне на e-mail (slavazanko(at)gmail.com)

Есть ещё be-tarask.po: http://www.midnight-commander.org/expor ... -tarask.po
Если кто возьмется - буду благодарен.

[Aleksey Kondratenko]

А когда наконец приложат #1637 ? Это ж минутное дело.

У меня теперь из-за этого бага 'git commit' молча виснет, если забыть руками сделать 'stty -tostop'

[slavaz]

Aleksey Kondratenko, сдвинулось.

[slavaz]

Кстати, всегда ли было такое поведение?
git commit - отрабатывает у меня нормально

[Aleksey Kondratenko]

На всех моих компах с debian unstable с недавних пор большинство gtk програм выдают на старте

GLib-WARNING **: g_set_prgname() called multiple times

в том числе и emacs. Не знаю как давно, но очевидно, git запускает редактор в отдельной группе процессов (видимо чтобы можно было легко прибить одним махом). И т.к. эта группа не foreground, то с настройками терминала, что специально выставляет mc, вывод этого warning-а привoдит к SIGTTOU, что останавливает emacs.

Как я уже говорил, судя по логам такое поведение mc это загон Мигеля. Ему показалось что так правильней, и он это сделал. Обычно это работает нормально, но это давно пора убрать, т.к. для большинства, что не посвящено в тонкости unix job control, такие баги не реально диагностировать. Я сам до недавних пор не знал, почему надо выходить из mc перед запуском многопоточной программы в GDB.

P.S. IMHO, вашему проекту стоит подумать о менее бюрократичном и более agile процессе review патчей. Вроде ж есть специальные сайты для этого.
P.P.S. Надеюсь мои "наезды" воспринимаются конструктивно. MC -- полезная программа и я регулярно ее пользую. Спасибо вам за работу над ней.

[slavaz]

Как я уже говорил, судя по логам такое поведение mc это загон Мигеля. Ему показалось что так правильней, и он это сделал. Обычно это работает нормально, но это давно пора убрать, т.к. для большинства, что не посвящено в тонкости unix job control, такие баги не реально диагностировать. Я сам до недавних пор не знал, почему надо выходить из mc перед запуском многопоточной программы в GDB.

Гм.. Интересные подробности. Спасибо за патч в люом случае Он уже в мастере. Завтра/послезавтра ждите релиза (тьфу-тьфу-тьфу).

P.S. IMHO, вашему проекту стоит подумать о менее бюрократичном и более agile процессе review патчей. Вроде ж есть специальные сайты для этого.

Ну два голоса за последний патч в бранче... не особо оно и бюрократично. Впрочем, про другие модели ревьювинга, если честно, я и не знаю Не с чем сравнить... а правила сами и придумали с год назад.

P.P.S. Надеюсь мои "наезды" воспринимаются конструктивно.

Наезды? Гм.. Вообще-то Ваши слова воспринимаются как здоровая критика и пожелания. Всё в норме, наездов не видно

[Aleksey Kondratenko]

Судя по моей почте, вы меняли статус билетика 8 раз. Если б я был на вашем месте, то я б столько не осилил

Вообще, имеется общая для всех free-software проектов проблема с contributions как со стороны maintainers, так и со стороны contributors.

Maintainers более-менее популярных проектов и так занимаются своим делом в проекте (часто в свободное от работы время) и еще вынуждены заниматься review сторонних патчей, желательно не забывая ни про какие патчи. Да я знаю, что многие патчи либо полный бред, либо неправильно оформлены (code style, missing test case, ...).

Contributors кроме того чтобы сделать багфикс/улучшение и правильно это все оформить должны еще совершать дополнительные телодвижения чтобы их патч приняли. Например, чтобы приняли ваш багфикс в Ruby On Rails нужно:

• * зарегистрироваться на lighthouse
  * сделать билетик с описанием бага и патчем
  * послать письмо в rails-core с убедительным описанием вашего случая и линком на билетик (иначе на ваш билет могут просто не обратить внимание)

У меня есть опыт именно с патчами для rails. И по моему ощущению, найденный и правильно исправленный баг это меньше половины дела. "Социально/бюрократичекий" аспект довольно таки тяжелый. И IMO гораздо больше чем это необходимо.

Учитывая, что большинство людей не являются регулярными contributors больших проектов, подобные "бюрократические" преграды для многих являются слишком большими. Я знаю много случаев когда люди исправляют баг, но "стесняются/леняться" даже отослать патч. Либо отославши и столкнувшись с социально/бюрократическим аспектом просто забивают.

Я думаю, мы теряем значительное количество contributions из-за этого. И явно, улучшать ситуацию надо для обоих сторон.

Я где-то/когда-то читал про сайты для облегчения code-review (никогда не пользовал; сейчас лениво это исследовать). Не исключено, что есть и сайты облегчающие весь цикл обработки патчей, как для contributors, так и для maintainers. Если нет, то было б неплохо что-то в этом роде сделать.

[slavaz]

Поднимаю тему переводов опять.

Мы участвуем в проекте Transifex. Проект: http://www.transifex.net/projects/p/mc/

Кто желает переводить - зарегайтесь на сайте и потом создайте запрос на добавление нового тима к проекту.
Переводы от вас будут напрямую коммититься в репозиторий.