<?xml version='1.0' encoding="utf-8"?>
      <rss version='2.0'>
      <channel>
      <title>Форум на Исходниках.RU</title>
      <link>https://forum.sources.ru</link>
      <description>Форум на Исходниках.RU</description>
      <generator>Форум на Исходниках.RU</generator>
  	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3300642</guid>
        <pubDate>Sat, 13 Apr 2013 08:26:06 +0000</pubDate>
        <title>Проверка орфографии исходного кода проекта (на примере Delphi 7)</title>
        <link>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3300642</link>
        <description><![CDATA[SourceLocalizer: Добавил автоматическую проверку орфографии на основе OpenOffice.<br>
Теперь после коммита можно увидеть (в JUnit-отчете на билд-сервере) какие ошибки добавились.<br>
Для локального использования - специальный ярлык, при &quot;броске&quot; файлов на который получаем отчет по орфографии в файлах.<br>
<br>
Подробней с примерами и скриншотами в моем блоге: <a class='tag-url' href='http://sourcelocalizer.blogspot.ru/2013/04/blog-post_13.html' target='_blank'>http://sourcelocalizer.blogspot.ru/2013/04/blog-post_13.html</a><br>
<br>
Своя проверка орфографии, вместо проверки в Word/OpenOffice-редакторе, позволяет отделить английские слова от основного (обычно русский) языка<br>
и проверять их отдельно. <br>
Обычно проще запретить проверку английского языка, чтобы не проверять английские термины/сокращения (AppData,..) в тексте.<br>
<br>
Автоматическая проверка орфографии, позволяет проверить свой код на явные ошибки перед передачей на проверку отчета корректору.]]></description>
        <author>SourceLocalizer</author>
        <category>Delphi: Общие вопросы</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3299772</guid>
        <pubDate>Wed, 10 Apr 2013 21:17:38 +0000</pubDate>
        <title>Проверка орфографии исходного кода проекта (на примере Delphi 7)</title>
        <link>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3299772</link>
        <description><![CDATA[cyber-pilot: <div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298029'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-07T13:28:38+00:00">07.04.13, 13:28</time></span><div class='quote '>Какие инструменты/методы проверок орфографии в своем коде используются в Ваших проектах?</div></div><br>
Я программульку написал, которая проверяет исходники программы, в том числе проверяет и орфографию.<br>
У нас довольно специфические программы, идет очень активная обработка строк. В коде часто встречаются обрезанные слова, префиксы, суффиксы и т.д. Поэтому если просто выдавать все слова, которых нет в орфографическом словаре, то получается большой список. И нужно много сил, чтобы их все проверить. Чтобы сократить эту работу, я выдаю только те слова, которые похожи на существующие в словаре.<br>
Проверяю весь проект, если нахожу ошибки, то исправляю их и потом все это коммичу на SVN. <br>
<a class='tag-url' href='http://ak-coder.blogspot.ru/' target='_blank'>Ссылка</a>]]></description>
        <author>cyber-pilot</author>
        <category>Delphi: Общие вопросы</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298590</guid>
        <pubDate>Mon, 08 Apr 2013 14:10:58 +0000</pubDate>
        <title>Проверка орфографии исходного кода проекта (на примере Delphi 7)</title>
        <link>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298590</link>
        <description><![CDATA[Fr0sT: <div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298575'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T13:28:54+00:00">08.04.13, 13:28</time></span><div class='quote '>Но самое главное - правка/дополнение документации процесс не прекращающийся и как отслеживать <br>
_изменение_ части документации, чтобы проверять только ее, а не _всю_ документацию.</div></div><div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298575'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T13:28:54+00:00">08.04.13, 13:28</time></span><div class='quote '>При разработке группой программистов, как Вы предлагаете/делаете отслеживание появившихся новых названий хинтов/кнопок/пр.?</div></div><div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298575'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T13:28:54+00:00">08.04.13, 13:28</time></span><div class='quote '>Сначала попробовали автоматически исправлять, но тогда надо править код сразу для разных программистов и потом согласовывать(мержить) с ними файлы,<br>
поэтому решили использовать приведенный отчет, так как по нему просто каждому поправить свои файлы.</div></div><br>
Собственно, если действительно есть потребность в поддержке проектов с хардкод-строками, и программа позволяет с этим как-то жить - не спорю, ради бога, и в добрый путь. Просто при правильной организации структуры системы все эти проблемы, как и необходимость в каком-либо дополнительном софте, просто не существуют. Правда, это касается только интерфейса. С комментариями сложнее, хотя можно отслеживать изменения по diff-ам сгенеренной на их основе документации. У меня пока данный вопрос вообще не воникал, поэтому пока задача не интересует.<br>
<div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298575'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T13:28:54+00:00">08.04.13, 13:28</time></span><div class='quote '>Будет возможность - перейдем. Пока используем delphi 7.</div></div><br>
Юникод можно с успешно юзать и в Д7<br>
<div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298575'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T13:28:54+00:00">08.04.13, 13:28</time></span><div class='quote '>Предлагаю вернуться к теме орфографии <br>
Интересен, в первую очередь, подход к исправлению орфографии, с учетом контроля версий <br>
и возможностей отслеживания изменений текста особенно на формах, а не проверки периодически всего проекта.</div></div><br>
А чего тут возвращаться? Как уже было сказано ранее, вынос текстовых ресурсов в отдельные файлы решает все проблемы, в т.ч. разделяет изменения кода и текстов. Что дает и диффы только на нужные для корректора файлы, и избавляет программеров от необходимости мержить в код то, что наворотил корректор. В любом случае, мое мнение тут чисто теоретическое, на практике все это пока не требовалось. Пусть выскажутся те, кто имел подобный опыт.<br>
<br>
P.S. Вообще тут есть ф-я цитирования, а то с этими уголками ничего не разберешь]]></description>
        <author>Fr0sT</author>
        <category>Delphi: Общие вопросы</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298575</guid>
        <pubDate>Mon, 08 Apr 2013 13:28:54 +0000</pubDate>
        <title>Проверка орфографии исходного кода проекта (на примере Delphi 7)</title>
        <link>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298575</link>
        <description><![CDATA[SourceLocalizer: Fr0sT,<br>&gt;&gt;С таким же успехом можно спеллчекить и выданную документацию.<br>Документация может быть представлена (javadoc) в виде большого набора html-файлов, что несколько затрудняет проверку.<br>при нахождении ошибки необходимо найти по классу файл, затем место в коде. Быстрей предлагаемый мной способ.<br>Но самое главное - правка/дополнение документации процесс не прекращающийся и как отслеживать <br>_изменение_ части документации, чтобы проверять только ее, а не _всю_ документацию.<br><br>&gt;&gt;1) Лично у меня обычно интерфейс весьма аскетичен на надписи, т.ч. 5-10 строк проверить не составляет труда<br>В больших проектах бывает много десятков форм и много сотен элементов на них. <br>При разработке группой программистов, как Вы предлагаете/делаете отслеживание появившихся новых названий хинтов/кнопок/пр.?<br><br>&gt;&gt;2) Еще раз, если проект нормальный - строковые ресурсы должны быть отделены как от кода, так и от дизайна...<br>Согласен. Поэтому и написал &quot;Это не хорошо, но бывает.&quot; Но этот пункт не главное, а просто лишний плюс моей программе за отслеживание такого кода :) <br><br>Программа создана для локализации в основном такого старого и не правильного подхода <br>с использованием жестко-закодированных строк, но может применяться и с ресурсными строками.<br><br>Но по этому пункту совершенно не буду спорить, так как такой подход не правильный &quot;но бывает&quot;, <br>и надо с таким кодом уметь работать (локализовывать/проверять орфографию)<br>без переделки больших проектов, только ради локалиазации/орфографии.<br><br>&gt;&gt;если же прога - поделка в основном для себя, то пара очепяток никакого вреда не нанесут и будут поправлены на основе багрепортов<br>При большом проекте будет неудобно перед клиентами за опечатки, поэтому багрепорт лучше оставить на крайний случай, <br>если останется, действительно, только пара опечаток.<br><br>&gt;&gt;если ваше средство дает какую-то степень автоматизации<br>Сначала попробовали автоматически исправлять, но тогда надо править код сразу для разных программистов и потом согласовывать(мержить) с ними файлы,<br>поэтому решили использовать приведенный отчет, так как по нему просто каждому поправить свои файлы.<br><br>Дальнейшие проверки будут производится только по измененному тексту, <br>т.е. с учетом ревизий системы контроля версий (например, svn).<br><br>&gt;&gt;Вот это вообще ужасть. Весь мир уже лет десять как перешел на Юникод,<br>Согласен. Лучше тогда привести пример с умлаутами и пр., например, для немецкого языка, который тоже нельзя использовать в 1251. <br><br>Полностью согласен. Будет возможность - перейдем. Пока используем delphi 7.<br><br>&gt;&gt;Кстати, какие именно настройки ОС командуют Дельфям сохранять текст на формах в cp1251<br>Сохранение в 1251 и юникоде зависит от версии - Delphi 5/6/7/... В D5 cp1251 (#000), D6/D7/.. юникод (#0000). <br>Использование простого текста в dfm позволяет легко переходить между D5/D6/D7, но это очень специфичная проблема.<br>Открытие dfm зависит от локализации системы - вместо кириллицы в юникоде будут знаки вопросов (для D7 на русской ОС и D7 на английской ОС).<br><br>&gt;&gt;настроек операционной системы <br>Поправлю фразу в описании на &quot;локализации операционной системы&quot; и дополню конкретными примерами. Спасибо.<br><br>Предлагаю вернуться к теме орфографии :)<br>Интересен, в первую очередь, подход к исправлению орфографии, с учетом контроля версий <br>и возможностей отслеживания изменений текста особенно на формах, а не проверки периодически всего проекта.<br><br>Спасибо.]]></description>
        <author>SourceLocalizer</author>
        <category>Delphi: Общие вопросы</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298521</guid>
        <pubDate>Mon, 08 Apr 2013 11:36:23 +0000</pubDate>
        <title>Проверка орфографии исходного кода проекта (на примере Delphi 7)</title>
        <link>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298521</link>
        <description><![CDATA[Fr0sT: <div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298324'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T07:50:19+00:00">08.04.13, 07:50</time></span><div class='quote '>Вероятно в resx или секциях ресурсов в коде. Как Вы их проверяете на ошибки?</div></div><br>
Кидается тому же корректору исходный файл. Ну или можно накидать простейшую софтину, которая выдавала бы ему ресурсы построчно, тем самым исключив вероятность покоцать формат файла ресурса.<br>
<div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298324'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T07:50:19+00:00">08.04.13, 07:50</time></span><div class='quote '>В старых проектах зачастую используются жестко-запрограммированные текстовые значения прямо в коде, часто разделенные переменными. Это не хорошо, но бывает.</div></div><br>
Бывает, но такие вещи, как правило, уже тысячу раз проверены, и заново их проверять нет смысла. А новые надо добавлять по-правильному (хотя бы выносить в секцию констант в модуле).<br>
<div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298324'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T07:50:19+00:00">08.04.13, 07:50</time></span><div class='quote '>Если используете JavaDOC или сходную технологию для документации, то ошибки в комментариях отразятся в документации к проекту. Обычно это внутренняя документация, но тоже неприятно.</div></div><br>
С таким же успехом можно спеллчекить и выданную документацию.<br>
<div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298324'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-08T07:50:19+00:00">08.04.13, 07:50</time></span><div class='quote '>Отдельный вопрос про формы - как Вы проверяете хинты/заголовки/пр.? Особенно когда все проверили, а через пару месяцев добавились десятки элементов на десятках форм - заново все перепроверять перед релизом? Как отслеживаются изменения в Вашем проекте?</div></div><br>
1) Лично у меня обычно интерфейс весьма аскетичен на надписи, т.ч. 5-10 строк проверить не составляет труда<br>
2) Еще раз, если проект нормальный - строковые ресурсы должны быть отделены как от кода, так и от дизайна (если же прога - поделка в основном для себя, то пара очепяток никакого вреда не нанесут и будут поправлены на основе багрепортов). В противном же случае я слабо представляю, как будет производиться, например, локализация на другой язык. Кроме того, фиксы строковых ресурсов будут идти в основной бранч проекта, захламляя историю версий не относящимися к коду коммитами. Это детский сад.<br>
<br>
На самом деле, самое интересное - вот здесь:<br>
<div class='tag-quote'><a class='tag-quote-link' href='https://forum.sources.ru/index.php?showtopic=374932&view=findpost&p=3298029'><span class='tag-quote-prefix'>Цитата</span></a> <span class='tag-quote__quote-info'>SourceLocalizer &#064; <time class="tag-quote__quoted-time" datetime="2013-04-07T13:28:38+00:00">07.04.13, 13:28</time></span><div class='quote '>После проверки корректором - правим файлы кода и формы.</div></div><br>
если ваше средство дает какую-то степень автоматизации (к примеру, одним кликом записывает исправленный текст на нужное место, либо генерит патчи и т.п.) - то оно может пригодиться в некоторых случаях (хотя и поощряет использование bad practice в дизайне структуры ПО). Если же все делается ручками программеров... :no: <br>
<br>
<div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>При разработке программ на Delphi, в зависимости от настроек операционной системы, текст в dfm-файлах может кодироваться кодами в Юникоде или Win-1251. При переносе исходного кода на компьютер, на котором по другому кодируется текст в dfm-файлах, такой текст будет заменен знаками вопросов. Решением для таких случаев является перевод кодов в обычный текст в стандартной кодировке Windows (обычно Win-1251).</div></div><br>
Вот это вообще ужасть. Весь мир уже лет десять как перешел на Юникод, а вы решили повернуть телегу вспять. Особенно будет интересно, когда вы попытаетесь &quot;перевести&quot; строку наподобие &quot;Ма&#769;ма мы&#769;ла ра&#769;му&quot;. Кстати, какие именно настройки ОС командуют Дельфям сохранять текст на формах в cp1251?]]></description>
        <author>Fr0sT</author>
        <category>Delphi: Общие вопросы</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298324</guid>
        <pubDate>Mon, 08 Apr 2013 07:50:19 +0000</pubDate>
        <title>Проверка орфографии исходного кода проекта (на примере Delphi 7)</title>
        <link>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298324</link>
        <description><![CDATA[SourceLocalizer: Fr0sT,<br>&gt;&gt;В нормально построенных проектах все строковые ресурсы и так хранятся отдельно.<br>Вероятно в resx или секциях ресурсов в коде. Как Вы их проверяете на ошибки?<br><br>В старых проектах зачастую используются жестко-запрограммированные текстовые значения прямо в коде, часто разделенные переменными. Это не хорошо, но бывает.<br><br>&gt;&gt;Остается только задача проверки комментариев, но она не так уж важна.<br>Если используете JavaDOC или сходную технологию для документации, то ошибки в комментариях отразятся в документации к проекту. Обычно это внутренняя документация, но тоже неприятно.<br><br>Отдельный вопрос про формы - как Вы проверяете хинты/заголовки/пр.? Особенно когда все проверили, а через пару месяцев добавились десятки элементов на десятках форм - заново все перепроверять перед релизом? Как отслеживаются изменения в Вашем проекте?<br><br>Спасибо.]]></description>
        <author>SourceLocalizer</author>
        <category>Delphi: Общие вопросы</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298271</guid>
        <pubDate>Mon, 08 Apr 2013 05:48:28 +0000</pubDate>
        <title>Проверка орфографии исходного кода проекта (на примере Delphi 7)</title>
        <link>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298271</link>
        <description><![CDATA[Fr0sT: В нормально построенных проектах все строковые ресурсы и так хранятся отдельно. Остается только задача проверки комментариев, но она не так уж важна.]]></description>
        <author>Fr0sT</author>
        <category>Delphi: Общие вопросы</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298029</guid>
        <pubDate>Sun, 07 Apr 2013 13:28:38 +0000</pubDate>
        <title>Проверка орфографии исходного кода проекта (на примере Delphi 7)</title>
        <link>https://forum.sources.ru/index.php?showtopic=374932&amp;view=findpost&amp;p=3298029</link>
        <description><![CDATA[SourceLocalizer: При разработке программ возможны опечатки в названиях кнопок, форм, вызываемых сообщений, а также различия терминологии, грамматические ошибки и пр.<br>
<br>
В ряде сред программирования применяется автоматическая проверка орфографии введенного текста, но не во всех средах (например, Delphi 7).<br>
<br>
Используемые системы интерактивной проверки хорошо справляются с опечатками, но менее эффективны при проверке грамматики, <br>
особенно когда строка формируется из фрагментов, а также они не дают возможности проверить терминологию.<br>
<br>
В своем проекте используем извлечение текста из файлов форм и кода для дальнейшей передачи корректору.<br>
После проверки корректором - правим файлы кода и формы.<br>
<br>
Пример отчета для проверки корректором<br>
<span class="b-attach" data-size="80513" data-hits="814" data-attach-id="28503" data-attach-post-id="0">
			<span class="b-attach__title"></span><a class='b-attach-link' href='https://forum.sources.ru/index.php?act=Attach&amp;type=post&amp;id=0&amp;attach_id=28503' title='Скачать файл' target='_blank'>c_002_small.jpg</a> (, : 814)
		</span><br>
<br>
Подробней: &quot;Проверка орфографии в исходном коде проекта&quot;<br>
<a class='tag-url' href='http://sourcelocalizer.blogspot.ru/2013/04/blog-post.html' target='_blank'>http://sourcelocalizer.blogspot.ru/2013/04/blog-post.html</a><br>
<br>
Проверка на готовом продукте тоже производится, но уже на завершающем этапе сдачи релизовой версии.<br>
Предлагаемый подход с извлечением текста из кодов позволяет проверить _все_ сообщения/названия в программе,<br>
а не специально имитировать все случаи работы программы для проверки сообщений которые появляются в редких случаях.<br>
<br>
Какие инструменты/методы проверок орфографии в своем коде используются в Ваших проектах?<br>
<br>
P.S. Предлагаемый подход особенно подходит для больших проектов с участием группы разработчиков.]]></description>
        <author>SourceLocalizer</author>
        <category>Delphi: Общие вопросы</category>
      </item>
	
      </channel>
      </rss>
	