웹 관리 인터페이스를 사용해 Discourse 문자열을 꽤 많이 수정했습니다. 편의상[1] 영어 이외의 버전은 무시했습니다. 당연히 이로 인해 각 언어 버전이 동기화되지 않은 상태입니다.
Fedora에서는 커뮤니티 기반 번역을 위해 Weblate를 사용합니다. (https://translate.fedoraproject.org/ 참조). 이 기능을 연동하고 싶습니다. 이상적으로는 영어 문자열이 관리 인터페이스를 통해 업데이트되면 Weblate로 전송되고, 번역이 완료되면 다시 돌아오는 전적으로 자동화된 워크플로우가 구축되기를 바랍니다.
이를 가장 잘 구현할 방법은 무엇일까요?
게으름. ↩︎
다음과 같이 API를 사용하여 통합을 구현하는 것입니다:
이것은 예비 개요입니다. 현재 API는 고정된 양의 번역 오버라이드만 반환하기 때문에, 기존 제한 사항을 정량화하기 위해 조사 중입니다. 즉, 작동하려면 해당 API 엔드포인트에 변경 사항이 필요합니다.
폴링은 괜찮은 것 같습니다 — 어차피 번역이 즉시 이루어지지는 않으니까요. 그런데 폴링 _기능_이 어떤 방식으로든 상태를 추적해야 하나요? 무상태(stateless)로 유지할 수 있으면 좋겠는데…
사이트에서 무언가를 추적할 필요는 없습니다. 상태 없이(stateless) 구현할 수 있어야 합니다.
폴링(polling)을 하려면 다음 경로의 GET 요청을 보내야 합니다:
/admin/customize/site_texts.json?locale=en&overridden=true&page=0
locale 매개변수는 필요에 맞게 조정하십시오. API는 최대 50개의 결과를 반환하며 페이지네이션(page 매개변수)을 지원합니다.
결과가 더 있을 경우 JSON에는 { "extras" : { "has_more" : true } }가 포함됩니다.
번역 오버라이드를 업데이트하려면 다음 경로로 PUT 요청을 보내야 합니다:
/admin/customize/site_texts/<id>
<id>를 번역하려는 문자열의 ID로 대체하십시오. 예: “js.user.username.instructions”.
PUT 요청의 페이로드에는 폼 데이터(Content-Type: application/x-www-form-urlencoded; charset=UTF-8)를 사용해야 하며, 다음 속성이 포함되어야 합니다:
site_text[value]: 번역 내용site_text[locale]: 로케일, 예: “en”기본적으로 텍스트 커스터마이즈 관리자 인터페이스가 사용하는 것과 동일한 API 호출을 사용해야 합니다.