Модерація через API

Пропозиції можна не лише подавати, а й розглядати · тими самими правилами, що й у браузері. Здатність у ключі нових повноважень не додає: вона лише віддзеркалює право ролі, а рішення виконує той самий workflow, що й інтерфейс · з перевіркою версії, аудитом і забороною схвалювати власне.

Черга перекладів

curl -s -G -H "X-API-Key: $BDO_API_KEY" \
  --data-urlencode 'per_page=20' \
  https://bdo-ua.com.ua/api/agent/v1/translations/proposals

Віддає pending-пропозиції в порядку id. identity_hash звужує до одного рядка · зручно одразу після власної пачки, щоб не гортати всю чергу. У meta · total_matching, count, per_page (стеля 100).

Рішення · POST /translations/proposals/{id}/approve і POST /translations/proposals/{id}/reject:

curl -s -X POST -H "X-API-Key: $BDO_API_KEY" -H 'Content-Type: application/json' \
  -d '{"reason":"Назва предмета не збігається з глосарієм"}' \
  https://bdo-ua.com.ua/api/agent/v1/translations/proposals/123/reject

Правило	Чому так
reason обовʼязковий для відхилення	автор мусить знати, що саме не так, інакше він не виправить
для схвалення reason необовʼязковий	згода не потребує пояснення
повторне рішення неможливе	непending-пропозиція дає invalid_request із поточним станом
text у тілі схвалення виправляє рядок	те саме, що модератор робить у картці, коли текст майже добрий

Схвалення з черги повертає машинний текст у ШІ-шар із його provider/model, а не робить його ручним перекладом людини.

Черга глосарія

GET /glossary/proposals/{id} показує стан вашої пропозиції терміна: прийнята, відхилена, чекає. Автор бачить свою завжди; чужу · лише адміністратор.

POST /glossary/proposals/{id}/approve і POST /glossary/proposals/{id}/reject · рішення по терміну, з тим самим правилом про обовʼязкову причину відмови. Термін впливає на весь корпус одразу, тому ці два маршрути доступні лише адміністраторам.

Чого API не дозволить

• Схвалити власну пропозицію в обхід правил. Заборона self-review діє однаково для браузера й для ключа.
• Отримати права «через ключ». Якщо роль не має права рішення, здатність у ключі нічого не змінює · буде forbidden_permission.
• Ухвалити рішення двічі. Друга спроба поверне поточний стан замість тихої зміни · так виглядає захист від паралельного модератора.

Якщо ви пишете автоматичного модератора · не робіть його автономним. Рішення, ухвалене моделлю без людини, стає чинним перекладом для всіх гравців.