Проверка орфографии исходного кода проекта (на примере Delphi 7) , Предлагаю вариант проверки орфографии за счет извлечения всех текстовых фрагментов и комментариев из исходного кода и передачу их на проверку корректору (или через word) и дальнейшую правку в коде по отчету корректора

При разработке программ возможны опечатки в названиях кнопок, форм, вызываемых сообщений, а также различия терминологии, грамматические ошибки и пр.

В ряде сред программирования применяется автоматическая проверка орфографии введенного текста, но не во всех средах (например, Delphi 7).

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

В своем проекте используем извлечение текста из файлов форм и кода для дальнейшей передачи корректору.
После проверки корректором - правим файлы кода и формы.

Пример отчета для проверки корректором
Прикреплённый файлc_002_small.jpg (78,63 Кбайт, скачиваний: 812)

Подробней: "Проверка орфографии в исходном коде проекта"
http://sourcelocalizer.blogspot.ru/2013/04/blog-post.html

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

Какие инструменты/методы проверок орфографии в своем коде используются в Ваших проектах?

P.S. Предлагаемый подход особенно подходит для больших проектов с участием группы разработчиков.

В нормально построенных проектах все строковые ресурсы и так хранятся отдельно. Остается только задача проверки комментариев, но она не так уж важна.

Fr0sT,
>>В нормально построенных проектах все строковые ресурсы и так хранятся отдельно.
Вероятно в resx или секциях ресурсов в коде. Как Вы их проверяете на ошибки?

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

>>Остается только задача проверки комментариев, но она не так уж важна.
Если используете JavaDOC или сходную технологию для документации, то ошибки в комментариях отразятся в документации к проекту. Обычно это внутренняя документация, но тоже неприятно.

Отдельный вопрос про формы - как Вы проверяете хинты/заголовки/пр.? Особенно когда все проверили, а через пару месяцев добавились десятки элементов на десятках форм - заново все перепроверять перед релизом? Как отслеживаются изменения в Вашем проекте?

Спасибо.

Цитата SourceLocalizer @ 08.04.13, 07:50

Вероятно в resx или секциях ресурсов в коде. Как Вы их проверяете на ошибки?

Кидается тому же корректору исходный файл. Ну или можно накидать простейшую софтину, которая выдавала бы ему ресурсы построчно, тем самым исключив вероятность покоцать формат файла ресурса.

Цитата SourceLocalizer @ 08.04.13, 07:50

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

Бывает, но такие вещи, как правило, уже тысячу раз проверены, и заново их проверять нет смысла. А новые надо добавлять по-правильному (хотя бы выносить в секцию констант в модуле).

Цитата SourceLocalizer @ 08.04.13, 07:50

Если используете JavaDOC или сходную технологию для документации, то ошибки в комментариях отразятся в документации к проекту. Обычно это внутренняя документация, но тоже неприятно.

С таким же успехом можно спеллчекить и выданную документацию.

Цитата SourceLocalizer @ 08.04.13, 07:50

Отдельный вопрос про формы - как Вы проверяете хинты/заголовки/пр.? Особенно когда все проверили, а через пару месяцев добавились десятки элементов на десятках форм - заново все перепроверять перед релизом? Как отслеживаются изменения в Вашем проекте?

1) Лично у меня обычно интерфейс весьма аскетичен на надписи, т.ч. 5-10 строк проверить не составляет труда
2) Еще раз, если проект нормальный - строковые ресурсы должны быть отделены как от кода, так и от дизайна (если же прога - поделка в основном для себя, то пара очепяток никакого вреда не нанесут и будут поправлены на основе багрепортов). В противном же случае я слабо представляю, как будет производиться, например, локализация на другой язык. Кроме того, фиксы строковых ресурсов будут идти в основной бранч проекта, захламляя историю версий не относящимися к коду коммитами. Это детский сад.

На самом деле, самое интересное - вот здесь:

Цитата SourceLocalizer @ 07.04.13, 13:28

После проверки корректором - правим файлы кода и формы.

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

Цитата

При разработке программ на Delphi, в зависимости от настроек операционной системы, текст в dfm-файлах может кодироваться кодами в Юникоде или Win-1251. При переносе исходного кода на компьютер, на котором по другому кодируется текст в dfm-файлах, такой текст будет заменен знаками вопросов. Решением для таких случаев является перевод кодов в обычный текст в стандартной кодировке Windows (обычно Win-1251).

Вот это вообще ужасть. Весь мир уже лет десять как перешел на Юникод, а вы решили повернуть телегу вспять. Особенно будет интересно, когда вы попытаетесь "перевести" строку наподобие "Ма́ма мы́ла ра́му". Кстати, какие именно настройки ОС командуют Дельфям сохранять текст на формах в cp1251?

Fr0sT,
>>С таким же успехом можно спеллчекить и выданную документацию.
Документация может быть представлена (javadoc) в виде большого набора html-файлов, что несколько затрудняет проверку.
при нахождении ошибки необходимо найти по классу файл, затем место в коде. Быстрей предлагаемый мной способ.
Но самое главное - правка/дополнение документации процесс не прекращающийся и как отслеживать
_изменение_ части документации, чтобы проверять только ее, а не _всю_ документацию.

>>1) Лично у меня обычно интерфейс весьма аскетичен на надписи, т.ч. 5-10 строк проверить не составляет труда
В больших проектах бывает много десятков форм и много сотен элементов на них.
При разработке группой программистов, как Вы предлагаете/делаете отслеживание появившихся новых названий хинтов/кнопок/пр.?

>>2) Еще раз, если проект нормальный - строковые ресурсы должны быть отделены как от кода, так и от дизайна...
Согласен. Поэтому и написал "Это не хорошо, но бывает." Но этот пункт не главное, а просто лишний плюс моей программе за отслеживание такого кода

Программа создана для локализации в основном такого старого и не правильного подхода
с использованием жестко-закодированных строк, но может применяться и с ресурсными строками.

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

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

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

Дальнейшие проверки будут производится только по измененному тексту,
т.е. с учетом ревизий системы контроля версий (например, svn).

>>Вот это вообще ужасть. Весь мир уже лет десять как перешел на Юникод,
Согласен. Лучше тогда привести пример с умлаутами и пр., например, для немецкого языка, который тоже нельзя использовать в 1251.

Полностью согласен. Будет возможность - перейдем. Пока используем delphi 7.

>>Кстати, какие именно настройки ОС командуют Дельфям сохранять текст на формах в cp1251
Сохранение в 1251 и юникоде зависит от версии - Delphi 5/6/7/... В D5 cp1251 (#000), D6/D7/.. юникод (#0000).
Использование простого текста в dfm позволяет легко переходить между D5/D6/D7, но это очень специфичная проблема.
Открытие dfm зависит от локализации системы - вместо кириллицы в юникоде будут знаки вопросов (для D7 на русской ОС и D7 на английской ОС).

>>настроек операционной системы
Поправлю фразу в описании на "локализации операционной системы" и дополню конкретными примерами. Спасибо.

Предлагаю вернуться к теме орфографии
Интересен, в первую очередь, подход к исправлению орфографии, с учетом контроля версий
и возможностей отслеживания изменений текста особенно на формах, а не проверки периодически всего проекта.

Спасибо.

Цитата SourceLocalizer @ 08.04.13, 13:28

Но самое главное - правка/дополнение документации процесс не прекращающийся и как отслеживать
_изменение_ части документации, чтобы проверять только ее, а не _всю_ документацию.

Цитата SourceLocalizer @ 08.04.13, 13:28

При разработке группой программистов, как Вы предлагаете/делаете отслеживание появившихся новых названий хинтов/кнопок/пр.?

Цитата SourceLocalizer @ 08.04.13, 13:28

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

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

Цитата SourceLocalizer @ 08.04.13, 13:28

Будет возможность - перейдем. Пока используем delphi 7.

Юникод можно с успешно юзать и в Д7

Цитата SourceLocalizer @ 08.04.13, 13:28

Предлагаю вернуться к теме орфографии
Интересен, в первую очередь, подход к исправлению орфографии, с учетом контроля версий
и возможностей отслеживания изменений текста особенно на формах, а не проверки периодически всего проекта.

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

P.S. Вообще тут есть ф-я цитирования, а то с этими уголками ничего не разберешь

Цитата SourceLocalizer @ 07.04.13, 13:28

Какие инструменты/методы проверок орфографии в своем коде используются в Ваших проектах?

Я программульку написал, которая проверяет исходники программы, в том числе проверяет и орфографию.
У нас довольно специфические программы, идет очень активная обработка строк. В коде часто встречаются обрезанные слова, префиксы, суффиксы и т.д. Поэтому если просто выдавать все слова, которых нет в орфографическом словаре, то получается большой список. И нужно много сил, чтобы их все проверить. Чтобы сократить эту работу, я выдаю только те слова, которые похожи на существующие в словаре.
Проверяю весь проект, если нахожу ошибки, то исправляю их и потом все это коммичу на SVN.
Ссылка

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

Подробней с примерами и скриншотами в моем блоге: http://sourcelocalizer.blogspot.ru/2013/04/blog-post_13.html

Своя проверка орфографии, вместо проверки в Word/OpenOffice-редакторе, позволяет отделить английские слова от основного (обычно русский) языка
и проверять их отдельно.
Обычно проще запретить проверку английского языка, чтобы не проверять английские термины/сокращения (AppData,..) в тексте.

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