Идея по инфраструктуре переводов

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Идея по инфраструктуре переводов

Инякин Александр
По поводу системы контроля за переводами.

Если взять то, что мы уже имеем, а именно svn-хранилище переводов и попытку отслеживания статуса документов добавлением "метаданных" Localization в комментариях в конце документа.

Проблема этой системы в том, что подавляющее большинство людей просто не вносило эти "метаданные" в документ. По крайней мере, так было с теми, которые я допереводил или подправлял. Ладно, это полбеды. Вторая проблема - это отсутствие какой-либо системы, способной собирать и обрабатывать эти "метаданные" соответственно давать статистику.

Возьмем эту методику и немного переделаем. Возложим работу по обработке "метаданных" на subversion.
В subversion есть очень интересный механизм. Каждому объекту, лежащему в хранилище, можно назначить так называемые "propeties" - свойства объекта в виде пары "ключ-значение".

Теперь самое интересное. Назначим каждому документу набор ключей:

status - draft/translated/edited/publicated
translator - name of translator
editor - name of editor
deprecated - true/false
originVersion - version of original document

ну и еще что-нить по ходу развития.

Дело в том, что subversion может отслеживать изменение данных свойств и хранить изменения в хранилище. Например, даже если содержимое документа не изменилось, а, допустим, свойство status сменилось с draft на translated, то это изменение будет зафиксировано в хранилище.

Эти свойства можно менять и читать, как с командной строки, так и через subversion API. Написав набор скриптов на стороне сервера можно получать статистику не старее последней фиксации в хранилище.

Что в итоге мы получаем:
1. Документ не засоряется данными Localization, которые кроме нас никому не нужны.
2. На человека возлагается только решение о смене свойства status документа. Остальные можно автоматизировать.
3. Требуются минимальные знания о subversion для переводчиков.
4. Получение статистики на момент последней фиксации в любое время.
5. Получение подробной статистики не только о статусе документа, но и о его хозяевах (переводчик, редактор), а так же продолжительности процесса перевода (можно видеть сколько времени занимает тот или иной этап).
6. Сравнивая версию документа в официальном хранилище со свойством originVersion получаем оперативную справку об устаревании переводов, а главное - на сколько (один день или пол года уже =) )

Вот такой набросок.

Это лишь идея, поэтому дополнения и пожелания приветствуются...
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-doc-ru] Идея по инфраструктуре переводов

Azamat Hackimov
Эти свойства можно менять и читать, как с командной строки, так и через subversion API. Написав набор скриптов на стороне сервера можно получать статистику не старее последней фиксации в хранилище.

Работающий пример API/скриптов можешь привести?

--
From Siberia with Love!
Reply | Threaded
Open this post in threaded view
|

Re: Re: [gentoo-doc-ru] Идея по инфраструктуре переводов

Инякин Александр


Работающий пример API/скриптов можешь привести?

Азамат, видишь-ли, я не знаком ни с какими языками, кроме С++.

Subversion C API точно есть. И список функций огромный. Наверняка там найдутся необходимые. Но С видимо не очень сгодится для скриптов на веб-сервере. Поэтому можно использовать обвязки на других языках - python или perl. Для них они тоже есть.

Кроме этого есть websvn, написанный на PHP и viewcvs на питоне. Можно порыться в их исходниках и найти что-нить интересное.

Надо кого-нить с большим опытом программирования, чтобы он помого сориентироваться.