[kde-russian] [JT] Улучшение процесса перевода KDE

[kde-russian] [JT] Улучшение процесса перевода KDE

[Rinat Bikov]

Здравствуйте, уважаемые!

У меня есть несколько предложений по улучшению процесса перевода KDE:
1. Задача-минимум - создать на http://code.google.com/ проект с
зазеркалированными файлами переводов с kde.org и давать право на
фиксацию всем желающим по запросу. Так, чтобы можно было часто
фиксировать изменения в общем месте, притом основной svn-репозиторий
на kde.org не перегружать множественными коммитами и комментариями
типа "Translated 5 lines in the file...". Из такого репозитория
изменения легко вливаются в основную ветвь переводов kde. Также в этом
случае над одним файлом смогут работать сразу несколько человек и всем
будет доступен последний вариант перевода (возможно неправильный).

2. Задача-максимум: проапгрейдить Lokalize, чтобы он не падал, и чтобы
мог использовать общий промежуточный svn-репозиторий (к примеру, всё
тот же, на code.google.com). Ну и по умолчанию чтобы после каждого
сохранения файла в нём производилось svn commit -m "Translated strings
... in the file ../file.po", svn update. Также чтобы в этом
svn-репозитории можно было бы хранить глоссарий и другие файлы
настройки Lokalize общие для всех и индивидуальные для каждого
переводчика.

P.S. Кросспост.
Что вы об этом думаете? :)

-- 
С уважением, Ринат Биков.

Re: [kde-russian] [JT] Улучшение процесса перевода KDE

[Alexander Wolf]

19 января 2011 г. 14:52 пользователь Rinat Bikov <becase@altlinux.org> написал:
> У меня есть несколько предложений по улучшению процесса перевода KDE:

Зачем умножать сущности сверх необходимого?

-- 
With best regards, Alexander

Re: [kde-russian] [sisyphus] [JT] Улучшение процесса перевода KDE

[Андрей Черепанов]

[-- Attachment #1: Type: Text/Plain, Size: 2442 bytes --]

19 января 2011 Rinat Bikov написал:
> Здравствуйте, уважаемые!
> 
> У меня есть несколько предложений по улучшению процесса перевода KDE:
> 1. Задача-минимум - создать на http://code.google.com/ проект с
> зазеркалированными файлами переводов с kde.org и давать право на
> фиксацию всем желающим по запросу. Так, чтобы можно было часто
> фиксировать изменения в общем месте, притом основной svn-репозиторий
> на kde.org не перегружать множественными коммитами и комментариями
> типа "Translated 5 lines in the file...". Из такого репозитория
> изменения легко вливаются в основную ветвь переводов kde. Также в этом
> случае над одним файлом смогут работать сразу несколько человек и всем
> будет доступен последний вариант перевода (возможно неправильный).
Ринат, твоё рвение похвально, но совершенно не в ту сторону. В российской 
команде перевода KDE уже сложился свой workflow, доказавший свою 
работоспособность. Лучше бы занялись действительно качественными переводами.

Что касается инфраструктуры онлайновой локализации, то она делается вашим 
покорным слугой: http://l10n.lrn.ru/online.
Прежде, чем городить новый проект, лучше обдумать регламенты того, что есть.
 
> 2. Задача-максимум: проапгрейдить Lokalize, чтобы он не падал, и чтобы
> мог использовать общий промежуточный svn-репозиторий (к примеру, всё
> тот же, на code.google.com). Ну и по умолчанию чтобы после каждого
> сохранения файла в нём производилось svn commit -m "Translated strings
> ... in the file ../file.po", svn update. Также чтобы в этом
> svn-репозитории можно было бы хранить глоссарий и другие файлы
> настройки Lokalize общие для всех и индивидуальные для каждого
> переводчика.
SVN морально устарел (чтобы ни говорили некоторые товарищи). Есть 
поддерживаемые в актуальном состоянии 
git://git.altlinux.org/people/cas/packages/kde-l10n-ru.git
git://git.altlinux.org/people/cas/packages/kde-l10n-ru-stable.git
(оттуда я коммичу через git svn dcommit)

А вспомогательные материалы никто не мешает хранить в апстримном SVN, 
обсуждать в рассылке, а заметки собирать на l10n.lrn.ru/wiki/Категория:KDE

Кроме того, намечается тенденция перехода от локальных приложений к облачным. 
Это вполне оправдано и для локализации, но инструментарий требует доработки.
Поэтому я готов принять любую помощь.

А теперь, после получения информации, подумайте, зачем заводить проекты на 
Google и поднимать свой сервер SVN?

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [kde-russian] [JT] Улучшение процесса перевода KDE

[Yuri Chornoivan]

> Здравствуйте, уважаемые!
> 
> У меня есть несколько предложений по улучшению процесса перевода KDE:
> 1. Задача-минимум - создать на http://code.google.com/ проект с
> зазеркалированными файлами переводов с kde.org и давать право на
> фиксацию всем желающим по запросу. Так, чтобы можно было часто
> фиксировать изменения в общем месте, притом основной svn-репозиторий
> на kde.org не перегружать множественными коммитами и комментариями
> типа "Translated 5 lines in the file...". Из такого репозитория
> изменения легко вливаются в основную ветвь переводов kde. Также в этом
> случае над одним файлом смогут работать сразу несколько человек и всем
> будет доступен последний вариант перевода (возможно неправильный).
> 
> 2. Задача-максимум: проапгрейдить Lokalize, чтобы он не падал, и чтобы
> мог использовать общий промежуточный svn-репозиторий (к примеру, всё
> тот же, на code.google.com). Ну и по умолчанию чтобы после каждого
> сохранения файла в нём производилось svn commit -m "Translated strings
> ... in the file ../file.po", svn update. Также чтобы в этом
> svn-репозитории можно было бы хранить глоссарий и другие файлы
> настройки Lokalize общие для всех и индивидуальные для каждого
> переводчика.
> 
> P.S. Кросспост.
> Что вы об этом думаете? :)

Я думаю, что версия Lokalize из trunk (1.3?) умеет хранить память переводов в базе данных SQL, что делает использование самых попсовых VCS с недоработанным интерфейсом и проблемами с обновлением версий переводов из репозитория (см. переписку переводчиков GNOME) совершенно излишним.

Из собственных впечатлений: проблема свободных и бесплатных переводов всегда была не в том, что «неправильно расселись», а в том, что желания переводчиков недостаточно даже для простого достижения какой-либо даже мизерной цели в большом проекте (обратите внимание на количество орфографических ошибок в переводах GNOME, а ведь это, как говорят некоторые товарищи, основная рабочая среда Linux с ~100% перевода).

Re: [kde-russian] [JT] Улучшение процесса перевода KDE

[Николай Шафоростов]

Я недавно закоммитил первичную поддержку удалённых памятей перевода (на PostgreSQL сервере), ещё в планах на ближайшее время доделать это (сделать многопользовательским) и quality assurance - проверка памяти переводов (соотв. файлов которые в ней отображены) на предмет ложных друзей переводчика (predefined list of) и ещё попробую реализовать позитивные проверки - типа если в predefined list дан определённый перевод слова (или несколько длопустимых), то Lokalize будет выдавать все сообщения в которых не найден этот перевод. Я сейчас обдумываю как это подавать пользователю, тобишь интерфейс

Re: [kde-russian] [sisyphus] [JT] Улучшение процесса перевода KDE

[Rinat Bikov]

19 января 2011 г. 12:55 Андрей Черепанов написал:
[...]
> Что касается инфраструктуры онлайновой локализации, то она делается вашим
> покорным слугой: http://l10n.lrn.ru/online.
Ещё бы там KDE переводить можно было...

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

> SVN морально устарел (чтобы ни говорили некоторые товарищи). Есть
> поддерживаемые в актуальном состоянии
> git://git.altlinux.org/people/cas/packages/kde-l10n-ru.git
> git://git.altlinux.org/people/cas/packages/kde-l10n-ru-stable.git
> (оттуда я коммичу через git svn dcommit)
GIT - это же распределённая система управления версиями, а я предлагал
хранить всё в одном месте.
И постараться объединить все плюсы оффлайн-перевода и онлайн-перевода
:) А в ваш git-репозиторий не все желающие могут получить право
вносить изменения.
[...]
> Кроме того, намечается тенденция перехода от локальных приложений к облачным.
> Это вполне оправдано и для локализации, но инструментарий требует доработки.
> Поэтому я готов принять любую помощь.
В php не силён...

> А теперь, после получения информации, подумайте, зачем заводить проекты на
> Google и поднимать свой сервер SVN?
1. Свой сервер svn поднимать не надо, у google он уже поднят для всех проектов.
2. Проект на гугл предлагается заводить только ради одного svn-сервера
для хранения переводов :).
3. Хочется иметь всегда актуальный файл переводов вне зависимости от
машины доступной в данный момент. Для этого, конечно, можно 1) каждому
желающему завести проект на github, но а) неудобно б) излишне в) пушка
по воробьям. 2) помочь вам с доработкой http://l10n.lrn.ru/online, но
по трудозатратам это выйдет дольше, чем просто создание гугло-проекта
(но я не говорю, что не нужно дорабатывать http://l10n.lrn.ru/online).

Собственно, ради 3-го пункта я это всё и предложил...

-- 
С уважением, Ринат Биков.

Re: [kde-russian] [sisyphus] [JT] Улучшение процесса перевода KDE

[Rinat Bikov]

19 января 2011 г. 14:57 пользователь Rinat Bikov написал:
> 3. Хочется иметь всегда актуальный файл переводов вне зависимости от
> машины доступной в данный момент.
Притом не тот перевод, который находится на kde.org, а тот, над
которым сейчас работает переводчик, не имеющий права коммита на
kde.org.

-- 
С уважением, Ринат Биков.

Re: [kde-russian] [JT] Улучшение процесса перевода KDE

[Alexander Potashev]

19 января 2011 г. 11:52 пользователь Rinat Bikov <becase@altlinux.org> написал:
> Здравствуйте, уважаемые!
>
> У меня есть несколько предложений по улучшению процесса перевода KDE:
> 1. Задача-минимум - создать на http://code.google.com/ проект с
> зазеркалированными файлами переводов с kde.org и давать право на
> фиксацию всем желающим по запросу. Так, чтобы можно было часто
> фиксировать изменения в общем месте, притом основной svn-репозиторий
> на kde.org не перегружать множественными коммитами и комментариями
> типа "Translated 5 lines in the file...". Из такого репозитория
> изменения легко вливаются в основную ветвь переводов kde. Также в этом
> случае над одним файлом смогут работать сразу несколько человек и всем
> будет доступен последний вариант перевода (возможно неправильный).

1. Почему короткие коммиты — это плохо? Я так не считаю.
2. Сейчас над одним файлов не могут работать несколько людей
одновременно? Работать-то они смогут, но когда придет время сравнивать
наработки и проверять переводы, возникнут те же проблемы, что и если
бы несколько человек работали с отдельным файлов и отправляли свои
варианты переводов в рассылку.

Хотя, доля смысла в общедоступном репозитории есть. Можно попробовать
вместо отправки файлов в рассылку выкладывать их в одном репозитории.
Например, сейчас "висят" непроверенными или неисправленными пара
файлов, которые просто так в рассылке уже не найдешь. Но все ли будут
изучать SVN или Git из-за желания перевести всего лишь 1 файл?


-- 
Alexander Potashev

Re: [kde-russian] [JT] Улучшение процесса перевода KDE

[Alexander Potashev]

19 января 2011 г. 14:52 пользователь Николай Шафоростов
<shafff@ukr.net> написал:
> Я недавно закоммитил первичную поддержку удалённых памятей перевода (на PostgreSQL сервере), ещё в планах на ближайшее время доделать это (сделать многопользовательским) и quality assurance - проверка памяти переводов (соотв. файлов которые в ней отображены) на предмет ложных друзей переводчика (predefined list of) и ещё попробую реализовать позитивные проверки - типа если в predefined list дан определённый перевод слова (или несколько длопустимых), то Lokalize будет выдавать все сообщения в которых не найден этот перевод. Я сейчас обдумываю как это подавать пользователю, тобишь интерфейс

Проверка ведь уже делается при помощи правил Pology.


-- 
Alexander Potashev

Re: [kde-russian] [sisyphus] [JT] Улучшение процесса перевода KDE

[Андрей Черепанов]

[-- Attachment #1: Type: Text/Plain, Size: 2976 bytes --]

19 января 2011 Rinat Bikov написал:
> 19 января 2011 г. 12:55 Андрей Черепанов написал:
> [...]
> 
> > Что касается инфраструктуры онлайновой локализации, то она делается вашим
> > покорным слугой: http://l10n.lrn.ru/online.
> 
> Ещё бы там KDE переводить можно было...
Технически это сделать не проблема. Только пока нет смысла туда заводить все 
переводы, не имея ответа как это будет обновляться и как переводы попадут в 
апстрим.
 
> > Прежде, чем городить новый проект, лучше обдумать регламенты того, что
> > есть.
> 
> Я проект городить не предлагал, я предлагал просто хранить переводы
> всех переводчиков в одном месте :).
Даже откровенно плохие? Зачем? Чем git не угодил?

> Притом не окончательные переводы, а черновой, рабочий, незаконченный
> вариант переводов с последующей их проверкой и внесением в основную
> ветвь.
представляешь, сколько на просмотр этой свалки уйдёт времени? И сколько будет 
найдено полезных находок?

> > SVN морально устарел (чтобы ни говорили некоторые товарищи). Есть
> > поддерживаемые в актуальном состоянии
> > git://git.altlinux.org/people/cas/packages/kde-l10n-ru.git
> > git://git.altlinux.org/people/cas/packages/kde-l10n-ru-stable.git
> > (оттуда я коммичу через git svn dcommit)
> 
> GIT - это же распределённая система управления версиями, а я предлагал
> хранить всё в одном месте.
Можешь раз в неделю делать бэкап SVN, потом через пару месяцев поискать по 
этой куче.

> И постараться объединить все плюсы оффлайн-перевода и онлайн-перевода
Какие?
 
> :) А в ваш git-репозиторий не все желающие могут получить право
> вносить изменения.
> [...]
Это вообще-то Git, _распределённая_ система управления версиями! То есть 
склонируй себе и делись своими наработками. А я, если нужно, замержусь.
 
> > Кроме того, намечается тенденция перехода от локальных приложений к
> > облачным. Это вполне оправдано и для локализации, но инструментарий
> > требует доработки. Поэтому я готов принять любую помощь.
> 
> В php не силён...
Там регламенты нужны, не только кодирование.
 
> > А теперь, после получения информации, подумайте, зачем заводить проекты
> > на Google и поднимать свой сервер SVN?
> 
> 1. Свой сервер svn поднимать не надо, у google он уже поднят для всех
> проектов. 2. Проект на гугл предлагается заводить только ради одного
> svn-сервера для хранения переводов :).
Заводите. Никто не мешает.

> 3. Хочется иметь всегда актуальный файл переводов вне зависимости от
> машины доступной в данный момент.
Обновляйтесь хоть раз в 5 минут.

> Для этого, конечно, можно 1) каждому
> желающему завести проект на github, но а) неудобно б) излишне в) пушка
> по воробьям. 2) помочь вам с доработкой http://l10n.lrn.ru/online, но
> по трудозатратам это выйдет дольше, чем просто создание гугло-проекта
> (но я не говорю, что не нужно дорабатывать http://l10n.lrn.ru/online).
> 
> Собственно, ради 3-го пункта я это всё и предложил...
Делайте. Пока это прекраснодушные фантазии.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [kde-russian] [JT] Улучшение процесса перевода KDE

[Rinat Bikov]

19 января 2011 г. 15:20 пользователь Alexander Potashev написал:
> Хотя, доля смысла в общедоступном репозитории есть. Можно попробовать
> вместо отправки файлов в рассылку выкладывать их в одном репозитории.
> Например, сейчас "висят" непроверенными или неисправленными пара
> файлов, которые просто так в рассылке уже не найдешь. Но все ли будут
> изучать SVN или Git из-за желания перевести всего лишь 1 файл?
Для того, чтобы не было необходимости всем изучать svn или git была
программа-максимум :).
Для гуи переводов нужно только commit, update и разрешать коллизии,
остальное смогут сделать специалисты, которые больше знают svn. А пока
его нет, можно просто в FAQ выложить описание 3-х операций (если что,
есть RapidSVN для людей, которых отпугивает консоль).


-- 
С уважением, Ринат Биков.

Re: [kde-russian] [JT] Улучшение процесса перевода KDE

[Alexander Potashev]

19 января 2011 г. 11:52 пользователь Rinat Bikov <becase@altlinux.org> написал:
> типа "Translated 5 lines in the file...". Из такого репозитория
> изменения легко вливаются в основную ветвь переводов kde. Также в этом
> случае над одним файлом смогут работать сразу несколько человек и всем
> будет доступен последний вариант перевода (возможно неправильный).

Предложите, как можно было бы осуществлять обратное слияние (из
основного репозитория в "общедоступный").

Например, человек "A" без доступа в основному репозиторию перевёл 3
строки в общедоступном репозитории. Проверяющий "B" одну строку принял
и добавил в основной репозиторий, вторую отверг полностью (т.е. ничего
не добавил в основной репозиторий), а третью немного изменил и тоже
добавил в KDE SVN.

Когда переводчик "A" будет вливать обновления переводов из основной
ветки в общедоступную, как он (точнее, его программа/сценарий)
определит, что стало со второй строкой: либо она была отвергнута, либо
проверяющий пока не решил, что делать с этой строкой (в обоих случаях
перевод строки будет отсутствовать в основной ветке).


-- 
Alexander Potashev