公開権限はローカリゼーションワークフローに属する

翻訳を依頼できる人が、自動的にそれを公開する権限まで持つべきではありません。

翻訳、レビュー、CMSへの反映、公開は、それぞれ結果の異なる別個のアクションです。ローカリゼーションツールがそれらを1つの権限に圧縮してしまうと、チームは広範なアクセス権を与えるか、遅くて中央集権的なプロセスを選ぶかの二択を迫られます。

よりよいワークフローは、編集組織がすでに信頼している境界を維持します。

重要な権限を分離する

少なくとも、ローカリゼーションの権限では、次のことを誰ができるかを区別すべきです。

• 翻訳リクエストを作成する
• 生成されたドラフトを編集する
• ローカライズ済みコンテンツを承認する
• 承認済みの値をCMSに反映する
• エントリーを公開または非公開にする
• プロジェクトのプロンプト、用語集ルール、自動化を変更する

小規模なチームでは、複数の権限を同じ人に割り当てることもあるでしょう。それでもこの区別は重要です。なぜなら、意図が明確になり、セキュリティモデルを作り直さずにワークフローを拡張できるからです。

権限の主体としてCMSを尊重する

ローカリゼーションアプリケーションは、Contentful の権限を迂回する近道になってはいけません。

接続されたユーザーまたは連携機能が、選択された環境でエントリーを公開できないなら、ローカリゼーションワークフローがそれをできるかのように扱うべきではありません。権限を早い段階で検証し、翻訳と反映は引き続き成功できることを示し、残っている公開ステップを明確に説明すべきです。

そうすることで、編集者がバッチ全体をレビューしたあとになって、ワークフロー内の誰にも最後まで完了できないことが判明するという、いら立たしい結果を防げます。

自動化にも同じルールを適用する

自動反映や自動公開は利便性のためのものであり、新たな権限の源ではありません。

自動化は、必要最小限の権限だけを持つ定義済みのIDのもとで実行されるべきです。リクエストには、誰がそのルールを有効にしたのか、どのプロジェクトと環境を対象とするのか、そして公開に事前レビューが必要かどうかを記録すべきです。

作業がキューに入っている間に権限が変更された場合は、実行前に再確認してください。先月保存された設定が、今日取り消されたアクセス権を上書きしてはいけません。

失敗状態を正確に保つ

公開中の権限エラーは、翻訳そのものを無効にするものではありません。

承認済みのドラフトと、成功したCMS更新は保持してください。公開フェーズはブロックされているとマークし、どの権限が不足しているのかを説明し、権限のある人がその地点から再開できるようにします。

リクエストを最初からやり直すのはレビュー作業を無駄にし、本当の問題も見えにくくします。フェーズごとの状態管理により、復旧はより速く、責任の所在もより明確になります。

職務分掌を前提に設計する

組織によっては、ある人がコンテンツを準備し、別の人がその公開を承認することを求めます。ワークフローは、システム外のメッセージに頼らずにそれを支援すべきです。

レビュアーは言語を承認し、市場責任者はロケールを承認し、公開担当者はエントリーを公開できます。それぞれの引き継ぎには、関連するプレビュー、ソースのスナップショット、ターゲット側の変更、監査履歴を含めるべきです。

職務分掌は、必ずしも終わりのない承認チェーンを意味する必要はありません。リスクが高い場合に適用し、低リスクのコンテンツはよりシンプルな経路に保ちましょう。

API呼び出しだけでなく意思決定も監査する

技術ログは、エンドポイントが成功を返したことは証明できます。しかし、編集監査にはより多くの文脈が必要です。

誰がドラフトを承認したのか、どのフィールドが反映されたのか、どの環境がそれを受け取ったのか、誰が公開を開始したのか、どのバージョンが本番化したのかを記録してください。自動化が動作した場合は、その背後にあるポリシーとIDも記録します。

その履歴があれば、チームは複数のシステムから再構築しなくても、リリースに関する問いに答えられます。

要点

ローカリゼーションは、言語、システム、権限の境界をまたいでコンテンツを動かします。

リクエスト、レビュー、反映、公開の権限を分離してください。現在のCMS権限を尊重し、自動化にも同じ制御を適用し、後続フェーズがブロックされた場合でも成功した作業は保持します。明確な権限境界があれば、すべての参加者に最終公開の鍵を渡さなくても、チームは迅速に動けます。