Статусы перевода должны отвечать на следующий вопрос

Системы перевода создают множество состояний. Задания ставятся в очередь, провайдеры отвечают, черновики сохраняются, Contentful обновляется, записи публикуются, и запускаются повторные попытки.

Отображение всей этой активности само по себе не делает прогресс понятным.

Полезный статус должен отвечать на следующий вопрос, который возникает у редактора.

У одного запроса несколько жизненных циклов

Многоязычный запрос часто проходит через три основные фазы:

1. перевод
2. отправка
3. публикация

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

«Завершено» может означать, что черновик перевода готов к проверке, целевая локаль была записана в Contentful или запись опубликована. Это существенно разные результаты.

Интерфейс должен называть фазу и её состояние вместе.

Статус и действие должны быть связаны

Редакторы смотрят на статус, чтобы понять, что они могут сделать дальше.

• Готовый перевод можно проверить.
• Одобренный перевод можно отправить.
• Успешную отправку можно опубликовать.
• Временный сбой можно повторить.
• Активную работу может быть возможно отменить.

Если доступное действие не соответствует отображаемому состоянию, продукт кажется непоследовательным. Кнопка публикации рядом с запросом, который никогда не был отправлен, не просто сбивает с толку; она подрывает доверие к базовому рабочему процессу.

Бэкенд должен определять доступность на основе устойчивого состояния и прав доступа, а затем UI должен последовательно отражать это решение.

Счётчикам прогресса нужен стабильный знаменатель

Прогресс пакета становится вводящим в заблуждение, когда каждая фаза использует разное общее количество без объяснения этого.

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

Прогресс должен различать:

• общее количество запросов
• запросы, подходящие для текущей фазы
• завершённые, активные, завершившиеся ошибкой и пропущенные запросы

Пропущенные особенно важны. Это финальное решение, а не незавершённая работа.

Сохраняйте историю, не перегружая экран

Текущее состояние должно оставаться компактным, но операторам всё равно нужна история, когда что-то идёт не так.

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

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

Финальные состояния должны оставаться финальными

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

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

Главное

Дизайн статусов — это часть рабочего процесса, а не декоративное оформление вокруг него.

Разделяйте фазы перевода, отправки и публикации. Связывайте каждое состояние с действием, которое оно делает возможным, честно учитывайте пропущенную работу и держите подробную историю под рукой. Лучший статус — тот, который делает следующее решение очевидным.