Сдача переводов: как проверить документы и языки

В папке десять файлов, а клиенту всё равно не хватает одного перевода. Так бывает, когда менеджер проверяет количество вложений вместо состава обещанного результата. Один документ перевели на два языка и сохранили в нескольких форматах, другой остался без нужной языковой версии. Большая папка выглядит готовой, хотя часть задания ещё открыта.

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

Разложите обещание клиенту на проверяемые результаты

В учебном заказе есть исходники А, Б и В. Каждый требуется перевести на английский и немецкий. Получается шесть обязательств: А–EN, А–DE, Б–EN, Б–DE, В–EN и В–DE. Для каждого согласованы редактируемый файл и PDF. Названия языков и форматов нужны только для примера: реальный состав определяют по договорённости с клиентом.

Не выводите обязательства автоматически из всех языков, известных бюро. Если документ В нужен только на английском, немецкая ячейка для него должна быть обозначена как не входящая в заказ. Пустое поле без такого различия заставляет сотрудника гадать: перевод забыли, он не требуется или условия ещё не согласованы. Состав задания сохраняют до проверки готовности.

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

Почему десять файлов не закрывают шестую ячейку

В примере готовы пять языковых результатов, каждый сохранён в двух форматах. Поэтому физических файлов десять, но покрытых обязательств только пять. Повторная копия PDF увеличит число вложений до одиннадцати и ничего не изменит в строке В–DE. Архивирование той же папки тоже не создаёт отсутствующий перевод.

Программа должна сворачивать варианты выдачи в одну позицию только по явной связи с заданием. Нельзя определять язык исключительно по суффиксу имени: файл могли назвать неправильно. Способ подтверждения этой связи задают в процессе работы. Для первой версии достаточно осознанного назначения сотрудником, если оно видно и поддаётся проверке. Автоматическое предположение не должно выглядеть как установленный факт.

Отдельно проверяют форматы внутри каждой позиции. Если для А–EN есть PDF, но нет согласованного редактируемого файла, перевод может быть подготовлен, а комплект выдачи ещё неполон. Полезно разделить эти состояния на экране. Тогда менеджер направит вопрос о недостающем формате нужному исполнителю, вместо того чтобы повторно заказывать весь перевод.

Пройдите комплект глазами следующего сотрудника

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

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

Показывайте причину незавершённости человеческими словами. «Нет В–DE» полезнее общего красного кружка у заказа. «Ожидается редактируемый файл А–EN» точнее, чем «не готово». Такой экран помогает разделить вопросы к переводчику, оформителю и менеджеру. Названия ролей можно изменить под команду, сохранив явную ответственность за оставшееся действие.

Новый исходник меняет конкретную часть комплекта

Предположим, клиент заменил А версии 1 на А версии 2. В учебной модели требуется заново подтвердить соответствие двух результатов: А–EN и А–DE. Готовые переводы Б и В не должны автоматически терять готовность только из-за изменения другого документа. Одновременно прежние результаты А нельзя незаметно объявить соответствующими новому исходнику.

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

В нашем примере после замены А остаются три подтверждённые позиции: Б–EN, Б–DE и В–EN. Открытых становится три: два результата для А версии 2 и ранее отсутствовавший В–DE. Это арифметика вымышленного реестра, а не оценка объёма новой работы. Она показывает, какие связи требуют решения, но не определяет стоимость и срок исправлений.

Согласованное исключение тоже должно быть видно

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

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

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

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

Что показать разработчику вместо общей просьбы о CRM

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

Следующий сценарий — замена только исходника А. Проверьте, что программа показывает зависимые языковые позиции и сохраняет объяснение прежней выдачи. Затем согласуйте частичную передачу и откройте заказ от имени другого сотрудника. Он должен увидеть отправленный состав и остаток работы без доступа к личным сообщениям предыдущего менеджера.

Расчёт стоимости можно вести отдельно: в статье про объём перевода и расчётные слова разобрано основание оценки. Для экрана сдачи критерий другой: каждому обещанному результату соответствует проверяемая позиция, её исходная версия и комплект файлов. Сначала добейтесь ясности на маленьком заказе, затем переносите модель на большие многоязычные проекты.