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

Человек, который может запросить перевод, не должен автоматически получать право его публиковать.

Перевод, проверка, доставка в CMS и публикация — это отдельные действия с разными последствиями. Когда инструмент локализации объединяет их в одном разрешении, командам приходится выбирать между широким доступом и медленным централизованным процессом.

Лучший рабочий процесс сохраняет границы, которым редакционная организация уже доверяет.

Разделяйте важные возможности

Как минимум, разрешения в локализации должны различать, кто может:

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

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

Уважайте CMS как источник полномочий

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

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

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

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

Автоматическая отправка в CMS и публикация — это удобства, а не новые источники полномочий.

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

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

Поддерживайте точные состояния ошибок

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

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

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

Проектируйте с учетом разделения обязанностей

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

Рецензент может утвердить язык, владелец рынка может санкционировать локаль, а издатель — выпустить запись. Каждая передача должна включать соответствующий предпросмотр, снимок исходника, изменения в целевом тексте и историю аудита.

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

Аудируйте решения, а не только вызовы API

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

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

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

Главное

Локализация перемещает контент через границы языка, систем и полномочий.

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