Добрый день!
Juliette Tux: "Ну я понимаю, что вызвала огонь на себя"
С моей стороны "огня" не будет )
Я не занимаюсь переводом системы gnome, opensuse, ubuntu, так как не обладаю достаточными знаниями
о контексте этих систем. Кроме того я не являюсь переводчиком, но долгое время работал
верстальщиком в газете и явные опечатки и неправильное использование отступов/дефисов/точек
замечаю всегда.
В том числе ошибки переводчиков заключающихся в забывчивости/пренебрежением точек/двоеточий/пробелов в переводимой конце строки и прочее.
Отчет "Для корректора" который я представил, как раз является "мостом" от систем локализации к обычному газетному корректору
который переводит обычно все на бумаге и обладает глубочайшими знаниями в проверке текста на ошибки/согласование/терминологию, но не разбирается в специальных системах локализации (а их масса, а не только на основе po).
"Проверка орфографии в исходном коде проекта"
http://sourcelocalizer.blogspot.ru/2013/04/blog-post.html
Поэтому подобный функционал добавлен в моей программе. При анализе системы локализации KDE
обнаружил pology которая во многом схожа с тем как я представляю такие системы :) только ее
явно черезчур усложнили и она не очень дружественна для неподготовленного человека (имхо),
особенно не сталкивающимся ранее с системами перевода.
Кроме того на мой взгляд мой подход будет более эффективным :) за счет сложения вычисления сразу
нескольких рег.выражений на основе текста и дальнейшего указаний в каких ситуациях это правильно/ошибка... причем все в очень простом виде для пользователя.
Советы локализатора OpenSuse позволили расширить и сделать более удобным отчет по ошибкам орфографии.
Свою программу разрабатывал на основе своей идеи локализации, которая была уникальна на фоне популярных систем локализации в системе windows... оказалось что идея в значительной мере совпадает с gettext...
Поэтому добавил множество решений превосходящих gettext и использующих его слабую сторону - работа только в runtime...
Например можно использовать код без добавления gt() и пр... оптимизация кода для локализации - из '1 ' + i + ' 2' в коде
собирается строка format('1 %d 2', i) которую можно локализовывать ЗАТЕМ даже gettext'ом...
По оптимизации кода можно прочитать:
"Автоматическая коррекция сложных жестко-запрограммированных текстовых значений для дальнейшей локализации"
http://sourcelocalizer.blogspot.ru/2013/03/blog-post_17.html#more
Из строки:
s:= 'Найдено ' + IntToStr(countdir) + ' каталогов, ' + IntToStr(countfile) + ' файлов.';
Получим:
s:= format('Найдено %s каталогов, %s файлов.', [IntToStr(countdir), IntToStr(count)]);
Сейчас нашел решение перемещать элементы интерфейса в зависимости от локали...
даже смогу преобразовывать автоматически код, чтобы gettext мог это делать на основе преобразованного моей программой кода программ...
Если есть ПО на основе gettext позволяющее корректировать интерфейс (менять положение кнопок, менять картинки, расширять кнопки для не влезающего текста и пр.), то напишите, пожалуйста.
Есть еще ряд задумок, поэтому активно исследую системы локализации чтобы не повторять уже придуманное... и найти актуальные задачи... хороший пример представленная Юлией задача, которая позволила проверить производительность моей программы на больших объемах текста и использовать отчет еще и в качестве поиска элементов интерфейса :)
Поэтому по ряду реализованных идей моя программа явно не является "велосипедом" :) так как
подобного функционала в других просто нет... или пока не нашел, но ищу...
По поводу windows-unix - моя программа кроссплатформенна (немного сильно сказано), за счет возможности работы на Mono...
Отсутствие перехода от необходимости запуска из wine и инсталлятора в стиле windows, заключается пока только в отсутствии win-версии ar-архиватора, без которого нельзя в windows собрать deb-пакет...
в gnuwin binutils не сделали win-версию... но в дальнейшем все сделаю :)
Предложенные выше изменения интерфейса, оптимизации кода и прочего полностью кроссплатформенны, так как код программ
не отличается существенно на разных платформах...
Программа ориентирована на работу на серверах сборки (например, hundson/jenkins) в почти любых средах (win/linux/...)
и использование кроссплатформенных средств обмена информацией присущих "непрерывной интеграции" - junit и в добавок txt/html.
Даже unix-программы похоже не все способны работать с junit, который является по сути центральным элементом локализации при непрерывной интеграции, в котором можно отслеживать ошибки, замечания, неточности и пр.
Буду рад советам и вопросам.
С уважением, Илья.
mailto:mail sourcelocalizer ru