Автоматическая выгрузка строк локализации и констант, используемых в тексте разработки.
При переносе разработки из одной базы в другую разработчик может столкнуться с рядом проблем. Одна из них - потеря строк локализации и констант, используемых в текстах разработки. При экспорте разработки данные строки автоматический не подгружаются, а добавление вручную занимает много времени и высока вероятность забыть/выбрать не те строки локализации.
Для решения данной проблемы нами был разработан сценарий выгрузки строк локализации и констант, используемых в тексте разработки.
Как это работает?
Сценарий запрашивает пакет разработки, который необходимо проанализировать, и добавить недостающие строки/константы.
Как видно из скриншота, можно указать не только основной пакет разработки, но так же и мастера действий, типовые маршруты и пользовательский события.
На основе выбранных пакетов разработки, сценарий:
- составляет список выгруженных компонент;
- с помощью регулярных выражений ищет строки локализации и константы, используемые в текстах разработки;
- формирует результирующий пакет разработки, состоящий из пакета разработки переданного в сценарий и найденных строк локализации и констант.
Поиск строк локализации и констант производится в следующих местах:
- Тексты сценариев;
- Тексты функций;
- Справочники, типы карточек электронных документов (вычисления реквизитов, пользовательский выбор, события);
- Блоки типовых маршрутов (параметр блока-сценария ТМ script, события);
- Отчёты (расчёт, шаблон);
- Мастера действий (события);
- Типовые маршруты (события).
Если какие либо строки локализации/константы не были найдены в БД, от куда происходит запуск сценария, то при включенной галке "Показать не найденные в БД строки" будет выведен список строк локализации/констант.
Архив с сценарием прилагается. Тестирование проводилось на версии 5.0.
Всем удачи и никогда ничего не теряйте :)
Еще можно поискать строки локализации на формах карточек. Бывает, что в карточке типа справочника для заголовка реквизита выбирается одна строка локализации, а для соответствующего контрола на форме — вторая, и эта вторая тоже не подтягивается автоматически утилитой экспорта и теряется.
На формах конечно может быть, но реализация сомнительна: парсить dfm-ку? По сути это единственное место, где строки остались без внимания. По крайней мере отсутствие строки в этом случае легко и очевидно отслеживается при открытии карточки. Больший риск касается строк локализаций, которые попадают в диалоговое окно не шибко часто.
При переносе из баз разработки в эталонку чаще всего теряются именно строки, на втором по популярности месте функции, но только лишь из-за того, что константы новые не так часто появляются. Было бы круче если бы напрямую к утилите экспорта/импорта прикрутили, возможно не так уж и сложно будет сделать - учитывая что программный код уже по факту имеется.
А итого: очень круто, повысит качество выпускаемых билдов, уменьшит трудоемкость их выпуска. Мы же производим автоматизированную систему, поэтому сверять строки локализации вручную не комильфо конечно. Спасибо разработчикам и проектировщикам, планирую вскоре опробовать "вживую".
Почему? Чем так страшны dfm? Думаю, те же регулярки помогут выловить из них локализацию. Есть нюансы с кодированием строк, да.
Верно. Только отслеживать по открытию карточки уже немного поздновато, если это происходит в продуктовой системе. Нужно снова идти в систему разработки и вручную искать и выгружать/добавлять в пакет потерянную строку.
Это как?
Да, думаю кодирование и имела в виду.
А как же множественное тестирование интерфейса?
Есть диалоговое окно, которое показывается в исключительных случаях, обработка редких ошибок. При неполном покрытии кода можно и не словить. Не только лишь диалоговые окна конечно, запись в логи тоже может содержать такие штуки
Авторизуйтесь, чтобы написать комментарий