Игорь ваша идея нереализуема, потому что чтобы что-то проверять надо сначала настроить проверки, коих у нас более 600. Трудно представить себе, что это делается с командной строки или из файла конфигурации ;).

Я просто скромно изложил факты :)

А потом, это же страшно неэффективно: прогонять проверки, получать отчёт, затем лазить в файлы, искать строку с ошибкой, исправлять, и так столько раз сколько строк в отчете.
В Ригоре в интерфейсе похожем на Visial Studo есть окошко со списком ошибок. Выбирается ошибка, автоматически открывается исходный файл и строка с ошибкой. Ее тут же можно исправить и она пропадает из списка ошибок. Можно false positives помечать скопом.
Пройтись и устранить 200 ошибок занимает от силы час. Исправления сразу фиксируются в файлах.

Всем приятных выходных!

Лезть в файлы конечно совершенно неэффективно, проще ж сразу из отчёта обновить.
В некоторых QA-тулах это давно есть. Именно это меня в 2011 году например и подкупило вообще в самом концепте autoQA

ну у меня задача сейчас просто понять, что там находится, и какие проверки нам нужны помимо тех, что у нас уже встроены (а у нас их немало, но это все технические проверки, не лингвистические).

и если уж там будет что-то стоящее, тогда уже думать, как прикрутить внутрь нашего интерфейса перевода, чтобы проверки делались по мере ввода текста

Имхо если у вас 200 ошибок по логу, то надо что-то в консерватории менять

Для этого надо файлы смотреть ;)

отдельного интерфейса для QA нам не надо (для нас это минус, а не плюс) 😉

Легко может быть в любом проекте.

Внутренний интерфейс перевода - это pootle?

ложные срабатывания, кстати, да, это отдельная тема. если проверки дают много false positives, то на них никто внимания обращать потом не будет. поэтому это тоже хотелось бы понять: куда сейчас дошли технологии лингвистического тестирования, и насколько они хороши из коробки. упомянутая выше lexiqa вроде предоставляет API и для проверки файлов целиком, и для живой проверки сегментов. буду копать в их сторону...

угу. вернее, то, во что он превратился после наших переделок

Пришлите xliff посмотреть, любопытно ;)

у нас только не XLIFF, а PO-файлы. могу прислать для примера пару файлов, если вы готовы прислать в ответ отчет )

Готов конечно.

У нас проверки не на сервере осуществляются. Тому есть серьёзные причины: а) очень много сложного кода, б) все делается в оперативной памяти, in-memory computing. Поэтому все работает очень быстро, даже с корпусами на миллион записей и с 5000 файлами в проекте. Боюсь, путль встроить в ригору проще, чем наоборот ;)

Почта: serge.gladkoff@logrusglobal.com. Интересно будет посмотреть!

нет, ну этим мы заниматься точно не будем (независимо от того, что куда встраивать). я сейчас пытаюсь найти что-то, что содержит хоть какие-то ошибки, и на чем можно протестировать. пришлю, как найду