Файл переведён, дедлайн близко, а Xbench показывает 500 предупреждений. Считать каждую строку ошибкой нельзя: отчёт QA показывает места для проверки, а решение о том, верен ли перевод, принимает человек.
Задача не в том, чтобы механически закрыть все строки или спрятать неудобные сигналы. Нужно быстро отделить потенциально опасные проблемы от повторяющихся ложных срабатываний, не потерять важные строки и оставить понятный след для ревьюера.
Что означает длинный отчёт Xbench¶
Проверки Xbench ищут потенциальные проблемы в файлах перевода. Они не сертифицируют качество и не объявляют каждую найденную строку ошибкой. В документации Xbench перечислены проверки пропусков, согласованности исходного и целевого текста, тегов, чисел, URL, буквенно-цифровых последовательностей, парной пунктуации, повторяющихся слов, пробелов, ключевых терминов, чек-листов и орфографии (описание проверок QA).
В отчёте на 500 строк могут одновременно находиться разные типы событий: очевидная опечатка, несогласованный термин, корректное имя продукта, допустимое повторение, особенность форматирования или фрагмент, который нужно оценить по контексту. Одинаковый статус в интерфейсе не означает одинаковую важность.
Полезно разделять три понятия:
- Срабатывание - строка, которую проверка выделила по заданному правилу.
- Потенциальная проблема - срабатывание, заслуживающее ручной проверки.
- Подтверждённая ошибка - проблема, которую ревьюер установил после проверки контекста и проектных требований.
Такое различие есть и в модели MQM: автоматическое обнаружение может показать потенциальную проблему, а последующая проверка подтвердит, что перевод корректен. В спецификации приводится пример с термином, заменённым местоимением по грамматическим причинам: сигнал есть, но ошибки нет (определение MQM).
В спецификации MQM сказано: “If human examination finds that the term was translated improperly, it is an error. However, examination might also find that the issue was not an error because the linguistic structure in the translation dictated that the term be replaced by a pronoun, so the translation is correct.”
Иными словами, строка становится ошибкой только после проверки. Например, отсутствие термина может быть грамматически оправдано, если в целевом сегменте на его месте стоит местоимение.
Отсюда следует практический принцип: сначала определите риск, затем выбирайте способ обработки. Опасное расхождение в числе нельзя приравнивать к безвредному различию форматирования, даже если обе строки отображаются в одном отчёте.
Перед запуском стоит также решить, что именно проверяется в этом проходе. Если проектная задача - проверить числа, пропуски и обязательные термины, включение всех возможных проверок не обязательно помогает. MQM рекомендует выбирать минимальный набор типов проблем, который соответствует требованиям пользователя (спецификация MQM). Для большой задачи это означает не «снять все галочки», а заранее описать цель QA-прохода.
Настройки влияют на результат. Например, Xbench отключает по умолчанию проверку Target same as Source: идентичный исходный и целевой текст может быть намеренным, а может указывать на непереведённый фрагмент. Проверка отмечает потенциальную проблему, а не автоматически решает, какой из этих случаев перед ней (диалог QA Xbench).
Проверки для CamelCase и полностью прописных соответствий также отключены по умолчанию в описанном диалоге QA. Поэтому отсутствие предупреждений не всегда означает, что конкретный риск проверен. В то же время включение дополнительных правил без понимания их последствий способно увеличить отчёт, не добавив полезной информации.
Полезно воспринимать QA как сортировщик внимания. Инструмент указывает, где посмотреть; переводчик проверяет, что именно произошло; проектные правила определяют, что исправлять. Подход к другим языковым ловушкам тоже строится на контексте: например, в материале о хибних друзях між українською та німецькою важна не похожесть слов сама по себе, а их значение в конкретной фразе.
Как расставить приоритеты и обработать 500 строк¶
Сортируйте предупреждения не по количеству в категории и не по порядку в отчёте, а по возможному ущербу. Предлагаемый ниже порядок - редакционная схема для первичного разбора, а не опубликованный Xbench рейтинг. Он основан на категориях проверок программы и на том, что может изменить смысл, повредить функцию или нарушить обязательное требование (перечень проверок QA).
Сначала проверьте смысловые пропуски¶
Начните со строк, где возможен пропуск части исходного сообщения или непереведённый текст. Такой сигнал может указывать на реально потерянное условие, предупреждение, отрицание или инструкцию. Сначала откройте сегмент и прочитайте его вместе с контекстом, а не только сравнивайте длину строк.
Если исходный текст включает несколько частей, проверьте, присутствует ли в переводе каждая значимая мысль. Совпадение общего тона не компенсирует отсутствующую оговорку. Уточните также, не осталось ли в целевом сегменте исходного фрагмента намеренно: названия интерфейса, имена собственные и незаменяемые элементы могут не переводиться по правилам проекта.
Здесь важна не механическая симметрия. Перевод может естественно перестраивать предложение, объединять или разделять его части. Проверка должна установить, сохранена ли информация, а не требуют ли две версии одинакового количества слов.
Затем разберите числа, URL и буквенно-цифровые строки¶
Расхождение в числе способно поменять значение инструкции, измерения или условия. Сверьте не только сами цифры, но и то, к чему они относятся, единицы измерения и окружающий текст. Если проект содержит форматированные значения, проверьте, не изменился ли разделитель или порядок записи.
URL и буквенно-цифровые последовательности тоже нужно смотреть в контексте. Предупреждение может указывать на случайно изменённую ссылку, идентификатор или код, но строка может быть допустимо локализована по инструкции. Не исправляйте её только ради совпадения с исходником: сначала выясните, какое правило действует для этого типа данных.
Практический способ ускорить такую проверку - открывать строки группами по типу сигнала и смотреть, повторяется ли одна причина. Если много строк связано с одним шаблоном или вариантом локализации, зафиксируйте правило и проверьте, что оно применимо ко всем случаям. Группировка не заменяет чтение: одно внешне похожее значение может играть другую роль в другом контексте.
Проверьте теги, которые влияют на функцию текста¶
Теги могут управлять форматированием, ссылками, переменными или другими элементами, которые не всегда видны читателю как обычный текст. Ошибка в их положении может повредить вывод или изменить поведение содержимого. Поэтому потенциальный tag mismatch нужно проверить на исходном и целевом сегментах, а при необходимости - в самом файле или в интерфейсе CAT-инструмента.
Не всякое различие тегов означает функциональную ошибку. Xbench предлагает параметр Ignore Tags для проверок согласованности: он позволяет сопоставлять текст, который в остальном совпадает, несмотря на различия встроенных тегов (описание QA-функций). Такая настройка полезна, если теги создают шум при поиске повторов, но не должна использоваться для маскировки реальной проблемы с тегом.
Показателен случай из форума Xbench: пользователь сообщил о предупреждениях для японской полноширинной пунктуации и символов, хотя не увидел неправильно размещённого тега. Участник обсуждения предложил отметить строку через Ctrl+M и скрыть помеченные результаты (обсуждение tag mismatch). Этот пример подтверждает, что отдельное срабатывание может оказаться ложным, но не доказывает, что все подобные сообщения безопасны.
После этого проверьте обязательную терминологию¶
Ключевой термин важен, если проект требует конкретного соответствия, а не просто предпочитает его. Проверьте, зафиксированы ли в глоссарии разрешённые варианты и связаны ли они с одним понятием. Затем прочитайте предложение: термин мог быть опущен из-за грамматики, заменён местоимением или употреблён в другой функции.
Когда найдено реальное несоответствие, исправляйте перевод или терминологические данные в первоисточнике проекта, а не только отметку в отчёте. Если оставить неверную запись в термбазе, предупреждение вернётся при следующем QA-проходе или затронет другие сегменты.
Только после этих проверок переходите к повторяющимся словам, пробелам, парной пунктуации и косметическим различиям. Часть таких сигналов действительно требует исправления, но их обычно удобнее разбирать сериями. Один и тот же лишний пробел может повторяться в большом количестве строк; исправление первопричины эффективнее, чем закрытие каждой записи без выяснения причины.
Разделите строки на три рабочих списка¶
Для большого отчёта используйте простую классификацию:
| Группа | Что делать | Что записать |
|---|---|---|
| Подтверждённая ошибка | Исправить сегмент или проектные данные, затем повторить нужную проверку | Причину и выполненное исправление |
| Ложное срабатывание | Проверить контекст и отметить строку, если исключение повторяется или его нужно сохранить | Почему строка корректна и при каких условиях |
| Требует решения | Передать вопрос лингвисту, редактору или владельцу требований | Контекст, альтернативы и критерий выбора |
Такая схема не позволяет свалить в одну корзину «исправлено», «не ошибка» и «непонятно». Три статуса отвечают на разные вопросы. Исправленная проблема больше не требует внимания; подтверждённое ложное срабатывание не должно отвлекать снова; спорный вариант нуждается в решении, а не в догадке исполнителя.
Сформулируйте правило отметки достаточно конкретно. Запись «ложное срабатывание» не объясняет следующему ревьюеру, почему строку скрыли. Запись вроде «ссылка должна оставаться на английском по проектной инструкции» уже указывает на проверяемую причину. Чем чаще встречается сценарий, тем полезнее хранить не только отметку, но и общее правило для команды.
Сохраняйте только подтверждённые исключения¶
В Xbench можно отметить отдельный результат и выбрать показ или скрытие отмеченных строк. Документация описывает этот механизм как способ убрать ложные сигналы из рабочей выдачи (работа с QA-функциями). Отметка - не способ закрыть неизвестную строку: прежде чем скрыть её, убедитесь, что содержимое действительно соответствует требованиям.
Цикл обработки выглядит так:
- Откройте строку и прочитайте исходный и целевой текст.
- Проверьте относящиеся к ней проектные требования, термины и формат.
- Исправьте подтверждённую ошибку или определите причину ложного срабатывания.
- Отметьте только проверенное исключение через Ctrl+M.
- Включите Hide Marked, чтобы сосредоточиться на неотмеченных строках.
- Повторите QA для тех типов проверок, которые менялись.
В обсуждении форума рекомендация сформулирована так: «To exclude false positives from the QA report, select the segment and press Ctrl+M to mark the issue. Then, at the QA options toolbar, select Hide Marked at the Filter Issues section» (ответ на форуме Xbench). Проще говоря: отметьте подтверждённое ложное срабатывание и включите Hide Marked. Ключевое здесь - сначала проверить строку, а уже потом убирать её из рабочего списка.
Отметки можно сохранить в файле .xbmrk, а затем загрузить снова. Это удобно, когда в повторяющихся проектах встречаются те же файлы или типовые ложные сигналы (документация о QA-отметках). Перед повторным использованием убедитесь, что исключение по-прежнему подходит: изменение глоссария, формата или проектных правил может превратить старую отметку в устаревшую.
Как уменьшить шум до запуска QA¶
Разбор отчёта начинается до нажатия кнопки запуска. Настройте охват проверки, выберите подходящие параметры и приведите в порядок повторно используемые правила. Такой подход помогает не только сократить рабочую выдачу, но и сделать её точнее.
Ограничьте проверку нужными сегментами¶
Xbench документирует запуск QA для новых сегментов и совпадений 100%, исключение сегментов ICE, а в описании рабочего процесса также перечисляет исключение заблокированных сегментов (QA workflow). Выбирайте область проверки в соответствии с задачей. Если нужно оценить недавно переведённое, проверка всего проекта может повторно показать уже разобранные сигналы и затруднить сравнение с предыдущим проходом.
Ограничение по сегментам не означает, что остальная часть файла гарантированно чистая. Оно означает только, что текущий проход отвечает на более узкий вопрос. Назовите этот вопрос в заметке к проверке: например, «проверить новые сегменты» или «повторно проверить изменённые термины». Тогда ревьюер не примет ограниченный отчёт за полный аудит.
Обращайте внимание на состояние сегментов. Если команда исключает ICE или заблокированные строки, заранее выясните, кто и по каким правилам проверяет их отдельно. Иначе фильтр снизит количество сигналов, но создаст слепую зону. Важно не максимальное число строк в отчёте, а соответствие области проверки ответственности команды.
Настройте согласованность под языковую задачу¶
Для проверки согласованности Xbench позволяет включить чувствительность к регистру. Если регистр влияет на различие названий, кодов или терминов, настройка может помочь. Если регистр свободно меняется по языковым правилам, слишком строгий режим создаст дополнительные предупреждения, которые ревьюер должен будет оценивать вручную (документация QA-функций).
Опция Ignore Tags работает иначе: она влияет на сопоставление при проверке согласованности и позволяет сравнивать текст без учёта различий встроенных тегов. Используйте её, если задача - найти несогласованные формулировки, а не сверить расположение тегов. Для проверки самих тегов нужен отдельный взгляд на предупреждения, которые отвечают за их структуру.
Также проверьте Target same as Source, CamelCase и варианты полностью прописных слов. В диалоге QA Xbench эти настройки описаны раздельно, и часть проверок выключена по умолчанию (диалог QA). Перед изменением настройте маленький тестовый участок или сравните результат с известными примерами проекта. Так можно понять, какой шум добавляет новая проверка, прежде чем применять её ко всему файлу.
Исправьте структуру термбазы¶
Большое число key term mismatch предупреждений может быть следствием не плохого перевода, а того, как записаны варианты в термбазе. В примере на форуме пользователь описал ситуацию, где каждый разрешённый перевод был отдельной записью. Предложенное решение - представить альтернативные варианты как синонимы одного понятия (обсуждение MultiTerm и key term mismatches).
В ответе участник форума советует: “You can avoid this issue if you define these entries as synonyms when you prepare the MultiTerm term base.”
Совет относится к устройству термбазы: допустимые варианты одного понятия полезно связывать между собой, чтобы система не трактовала каждую альтернативу как независимое противоречие. Проверяйте такое изменение на проектных правилах: синонимы уместны только тогда, когда варианты действительно взаимозаменяемы.
Перед редактированием термбазы выясните, что означает каждая запись. Два похожих термина могут различаться по домену, аудитории, части речи или контексту. Объединение таких записей ради уменьшения отчёта снимет предупреждения, но способно стереть значимое различие.
Документация Xbench отдельно описывает настройку whole-word matching для QA ключевых терминов. Если параметр не включён, поиск может давать ложные сигналы для языков с изменяемыми окончаниями; использование настройки требует учёта особенностей языка (раздел настроек Miscellaneous). Не включайте или выключайте её автоматически для всех языков: сначала проверьте, как правило ведёт себя на конкретных формах и требованиях проекта.
Используйте чек-листы для правил, которые повторяются¶
Чек-листы Project и Personal позволяют задавать повторяемые поисковые проверки. В документации Xbench среди примеров перечислены запрещённые слова, частые ошибки, отзывы клиента и проектные непереведённые ключевые слова (управление чек-листами). Это полезно, когда команда снова и снова ищет один и тот же тип проблемы и хочет применять понятное правило, а не надеяться на память ревьюера.
Project checklist хранится вместе с проектом .xbp, а Personal checklist - в файле .xbckl и может использоваться в разных проектах (документация чек-листов). Выбор зависит от масштаба правила. Клиентский запрет на конкретный термин относится к проекту; личная проверка опечатки, полезная в разных задачах, может быть частью персонального списка.
Запись чек-листа можно протестировать на загруженном проекте до использования. Отдельную запись можно отключить; состояние отключения сохраняется на диске (порядок работы с чек-листами). Тестируйте правила на известных примерах: хотя бы убедитесь, что выражение находит нужный случай и не выделяет очевидные корректные употребления.
Для контекстно-зависимых терминов одной проверки подстроки может быть недостаточно. Форумный пример предлагает использовать условия PowerSearch в чек-листе, чтобы учитывать контекст и допустимые варианты целевого термина вместо того, чтобы считать каждое вхождение фрагмента исходного слова одинаковым (обсуждение ключевых терминов). Это не готовое универсальное правило: условия нужно проектировать под реальные случаи из проекта.
Задайте масштаб проверки по требованиям, а не по максимуму возможностей¶
Стандарты оценки перевода полезны как рамка для решений, но не заменяют конкретные инструкции клиента. ISO 5060:2024 описывает аналитическую оценку переводов через типы ошибок и штрафные баллы, а также рассматривает компетентность оценщиков и выборку (ISO 5060:2024). Перед применением стандарта или схемы оценки сверяйте актуальную редакцию и требования проекта.
Практический вывод прост: сначала перечислите, какие типы ошибок действительно важны для результата. Для одного файла приоритетны числа и ссылки, для другого - обязательные термины и пропуски, для третьего - структура тегов. Не включайте проверку лишь потому, что она доступна. Но и не отключайте её только потому, что она создаёт много сигналов: выясните, можно ли уточнить правило или обработать повторяющиеся исключения отметками.
Разница между «отчёт стал короче» и «отчёт стал полезнее» принципиальна. Первое можно получить фильтром. Второе требует настройки правил, проверки контекста и прозрачной записи решений.
Когда скрывать предупреждения, а когда оставлять в выдаче¶
Фильтры помогают управлять вниманием, но решение о видимости влияет на работу команды и содержание экспорта. Выбирайте режим с учётом цели: внутренний разбор, передача неразобранных вопросов или сохранение полной истории проверки.
Скрывайте только подтверждённые ложные срабатывания¶
Скрытие уместно, когда ревьюер уже установил, что строка соответствует требованиям. Например, теговое предупреждение проверено в контексте, нужные теги стоят на месте, а различие объясняется особенностью символов или форматирования. Отметка сохраняет память о решении и позволяет убрать такой случай из текущего списка.
Не скрывайте строку, если неизвестно, почему она появилась. Неопределённость - не ложное срабатывание. Если сигнал может указывать на изменение смысла, неправильную ссылку, тег или обязательный термин, оставьте его видимым до проверки или передайте специалисту, который может принять решение.
Повторяющиеся исключения полезно сопровождать коротким объяснением. Тогда следующий участник проекта понимает не только то, что строка скрыта, но и условие, на котором основано решение. Для проекта с меняющимися требованиями добавьте повод пересмотреть отметку: обновление глоссария, шаблона или клиентской инструкции.
Помните, что экспорт зависит от фильтра¶
Экспорт результатов QA включает только те проблемы, которые отображаются в текущем окне; скрытые строки в экспорт не входят (документация экспорта QA). Поэтому перед созданием файла для клиента, редактора или аудита проверьте фильтр. Отчёт с Hide Marked отвечает на вопрос «что осталось неразобранным среди видимых строк», но не показывает все исходные срабатывания.
Диалог QA позволяет выгружать отображаемые результаты в HTML, текст с табуляцией, Excel или XML (форматы экспорта QA). Формат выбирайте по дальнейшему процессу: таблицу удобно дополнять статусами и комментариями, а машинно-читаемое представление может быть полезно для обработки в других инструментах. Сам по себе формат не сохраняет скрытые результаты.
Для передачи неразрешённых проблем экспортируйте видимые строки после проверки отметок. Для аудита сохраняйте также полный, неотфильтрованный результат до скрытия строк или повторно выгружайте его с соответствующим фильтром. Иначе принимающая сторона увидит только часть истории и может ошибочно решить, что пропущенные сигналы не возникали.
Держите два представления: рабочее и полное¶
Практично разделять оперативную выдачу и запись о полном запуске. Рабочий вид содержит строки, которые ещё требуют решения. Полный вид сохраняет контекст: какие сигналы появились изначально и какие из них отметили как подтверждённые исключения.
Такое разделение особенно полезно, если отчёт передаётся между переводчиком, редактором и менеджером проекта. Редактору может не понадобиться длинный список уже проверенных ложных сигналов; менеджеру проекта может понадобиться понимать, почему строка скрыта; аудитору может требоваться первоначальная картина проверки. Один файл не всегда отвечает всем трём задачам.
Не называйте отфильтрованный экспорт «полным отчётом», если в нём скрыты строки. Уточните состояние фильтра в имени файла или сопроводительной заметке. Это простое действие предотвращает недоразумение: получатель знает, видит он все срабатывания или только неразобранные.
Относитесь к отметкам как к решениям, которые нужно проверять¶
Сохранённый .xbmrk облегчает повторную работу, но отметка не становится истинной навсегда. Правила терминологии могут измениться, ранее допустимый вариант могут запретить, а файл может использоваться в новом контексте. Перед загрузкой сохранённых отметок проверьте, соответствуют ли они текущему проекту (описание сохранения QA marks).
Для команды полезно договориться о минимальной процедуре: кто имеет право отмечать строки, какие случаи требуют комментария и кто пересматривает повторно используемые отметки. Не нужно превращать каждый QA-проход в бюрократию. Достаточно, чтобы отметка отражала принятое решение, а не желание уменьшить число строк на экране.
Типичные ошибки при разборе Xbench QA¶
Сократить большой отчёт можно быстро, но несколько привычек приводят к тому, что вместе с шумом исчезают настоящие проблемы.
Считать все строки ошибками. Автоматическая проверка показывает потенциальные проблемы, а не подтверждённый дефект. Пройдитесь по контексту и проверьте, что именно означает сигнал.
Скрывать всё, что встречается часто. Большое число одинаковых предупреждений может указывать на системную проблему - например, на структуру термбазы или слишком широкое условие поиска. Сначала выясните общую причину, потом решайте, следует ли исправить настройку, изменить правило или отметить конкретные исключения.
Исправлять перевод ради совпадения с исходником. Совпадение токенов не всегда равно смысловой точности. Местоимение, грамматическая перестройка или допустимая локализация могут быть правильными. Решение должно опираться на контекст и требования, а не на желание обнулить категорию.
Отключать проверку, потому что она шумит. Неудобный отчёт может означать, что параметр не подходит для конкретного языка или проекта. Но отключение без проверки убирает не только ложные сигналы. Сначала оцените типичные срабатывания и альтернативные настройки.
Объединять разные понятия в термбазе. Синонимами должны быть действительно взаимозаменяемые варианты одного понятия. Если формулировки применяются в разных контекстах, искусственное объединение способно ухудшить проверку терминологии.
Экспортировать, не глядя на фильтр. Скрытые строки не входят в экспорт отображаемых результатов. Перед передачей проверьте, какой набор виден, и сохраните полный отчёт отдельно, если важна история.
Принимать старые отметки без повторной проверки. .xbmrk помогает переносить решения, но проектные требования могут измениться. Убедитесь, что исключение по-прежнему корректно, прежде чем скрывать его в новом цикле.
Гнаться за нулём предупреждений. Нулевой отчёт может означать исправление всех подтверждённых проблем, а может - слишком узкую область проверки, отключённые правила или скрытые строки. Оценивайте качество процедуры, а не только число видимых записей.
Хорошая проверка оставляет понятный результат: подтверждённые ошибки исправлены, ложные сигналы объяснены и при необходимости отмечены, открытые вопросы переданы нужному человеку, а экспорт соответствует своему назначению. Для повторяющихся ошибок полезно заранее сверяться с чек-листом переводческой специализации и терминологии: единые правила помогают отличать обязательный термин от одного из допустимых вариантов.
Перед закрытием отчёта задайте себе несколько вопросов: проверены ли числа и ссылки, просмотрены ли функционально важные теги, сверены ли обязательные термины, сохранена ли полная версия, если она нужна для аудита? Такой финальный проход не заменяет языковую редактуру, но снижает риск того, что опасная строка затеряется среди косметических сигналов.
Частые вопросы¶
Как скрыть ложные срабатывания в отчёте Xbench?¶
Выберите строку, нажмите Ctrl+M, а затем включите Hide Marked в панели фильтра результатов. Сначала проверьте строку по контексту: скрытие убирает её из текущего списка, но не доказывает, что она была безвредной (документация QA-функций).
Как уменьшить предупреждения Xbench о несовпадении ключевых терминов?¶
Проверьте, не записаны ли варианты перевода одного понятия как отдельные независимые записи. В обсуждении форума предложено хранить такие варианты как синонимы; контекстные различия лучше обрабатывать отдельными условиями чек-листа (форум о key term mismatches).
Какие предупреждения Xbench исправлять в первую очередь?¶
Сначала проверяйте возможные пропуски смысла, числа и URL, функционально важные теги и обязательную терминологию. Такой порядок - практическая схема сортировки по риску, а не официальная иерархия Xbench.
Можно ли сохранить отмеченные ложные срабатывания Xbench?¶
Да. Отметки можно сохранить в .xbmrk и повторно загрузить для повторяющихся проектов или файлов (работа с QA-отметками). Перед повторным использованием проверьте, не поменялись ли требования и контекст.
Почему Xbench показывает tag mismatch, если тег выглядит правильно?¶
Срабатывание может быть связано с символами или форматированием, а не с очевидным смещением тега. Форумный случай с японской полноширинной пунктуацией показывает, что такая ситуация возможна, но каждую строку всё равно нужно проверять отдельно (обсуждение tag mismatch).
В каком формате можно экспортировать результаты QA Xbench?¶
Диалог QA позволяет экспортировать отображаемые результаты в HTML, текст с табуляцией, Excel или XML (документация диалога QA). Скрытые строки в этот экспорт не попадут, поэтому для полной истории сохраните неотфильтрованный отчёт отдельно.