2008-09-03 5 views
9

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

  • Не все строки пользователя видны, и это нетривиально spearate их, и держать, что разделение на месте (но это возможно)
  • Большинство, если не все методы строковой экртизации, которые я использовал, включают значительный текст, который не пройдет проверку орфографии, такую ​​как aspell/ispell (например: theStrName = "some string.") и
  • Многие проверки орфографии (еще раз, aspell/ispell) не обрабатывать много слов из коробки (как правило, технические термины, собственные существительные или просто «новая» терминология, например метаданные).

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

+1

Я никогда не видел это автоматизированным, но если да, сделайте это предупреждением сборки, а не ошибкой. Последнее, что вы хотите на своих руках, - это неудачная сборка, потому что какой-то словарь знает только «электронную почту», а не «электронную почту» – slf 2009-09-09 15:35:37

+0

ах, очень хорошая точка! – rcreswick 2009-09-09 23:44:07

ответ

1

Мы делаем это вручную, если ошибки не выявляются во время тестирования, тогда они подбираются командой QA или во время локализации переводчиками или во время локализации QA. Затем мы вводим ошибку.

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

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

Как только ваше приложение созревает, более 90% строк не будут меняться между выпусками, и было бы достаточно тривиальным упражнением сравнить две версии ваших ресурсов, выяснить, что нового (сначала проверьте их) что изменилось/обновлено (проверьте далее) и что не изменилось (нет необходимости их проверять)

Так что подумайте об этом больше, так как мне нужно сначала проверить ВСЕ эти вручную, и я только собираюсь должны проверить 10% из них в следующий раз. Теперь спросите себя, действительно ли вам по-прежнему нужно автоматизировать проверку орфографии.

-1

Использование aspell. Это программа, она доступна для unixoids и cygwin, ее можно запустить по многим типам исходного кода. Используй это.

-2

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

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

В-третьих, это, пожалуй, наиболее легко решить, если люди сделают это: команда QA, копирайтеры, бета-тестеры, переводчики и т. Д.Все крупные сайты с интернационализированным контентом, которые я построил, имели один и тот же процесс: мы взяли копию из копирайтеров, отправили ее в переводческую службу/агентство, поместили ее в слой сохранения и развернули. Тестеры (QA, разработчики, PM, дизайнеры и т. Д.) Могли бы найти орфографические или грамматические ошибки и сообщать об ошибках. Существует слишком много волокиты и пар глаз для , что многие ошибки орфографии/грамматики проскальзывают.

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

1

я могу думать о двух способах подойти к этому полуавтоматический:

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

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

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

1

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

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

1

Если вы используете java и сохраняете свои локализованные строки в пакетах ресурсов, вы можете проверить файлы Bundle.properties и проверить строковые строки. Вы также можете добавить специальную аннотацию комментария, которую может использовать ваш процессор, чтобы определить, следует ли пропустить запись.

Этот метод позволит вам дать подсказку относительно языкового стандарта и обеспечить способ проверки нескольких языков в рамках одного процесса сборки.

Я не могу ответить, как вы будете выполнять фактическую проверку орфографии, хотя я думаю, что то, что я представил, будет направлять вас на способ выполнения проверки орфографии.

Смежные вопросы