페이지 번역을 생성하기 위한 프로그래밍 인터페이스를 찾을 수 없습니다. 모든 로직은 wagtail.contrib.simple_translation.views.

따라서 프로그래밍 방식으로 액세스하는 유일한 방법은 뷰 액세스 요청을 시뮬레이션하는 것입니다. 나는 이것을translate_page()라는 함수로 감쌌습니다. 페이지를 번역하기 위해 이 함수를 다음과 같이 호출할 수 있습니다:-

page_ja = translate_page(user, page, "ja")

또는 선택적 매개변수 include_subtree:-
를 전달할 수도 있습니다.

page_ja = translate_page(user, page, "ja", include_subtree=True)

그리고 함수는 다음과 같이 정의됩니다:-

def translate_page(user, page, lang, include_subtree=False):
    locale, created = Locale.objects.get_or_create(language_code=lang)
    data = {"locales": [locale.id], "include_subtree": include_subtree}
    url = reverse(
        "simple_translation:submit_page_translation", kwargs={"page_id": page.id}
    )
    factory = RequestFactory()
    request = factory.post(url)
    request.POST = data
    request.user = user
    get_response = lambda request: None
    middleware = SessionMiddleware(get_response)
    middleware.process_request(request)
    request.session.save()
    messages = FallbackStorage(request)
    setattr(request, "_messages", messages)

    SubmitPageTranslationView.model = type(page)
    SubmitPageTranslationView.as_view()(request, page_id=page.pk)
    page_translated = page.get_translations()[0].specific
    return page_translated

translate_snippet()이라는 또 다른 함수가 있습니다. 유일한 차이점은 제출할 URL만 있고 include_subtree 매개변수는 없다는 점입니다.

페이지 트리 문제

모든 사이트에는 개발자가 수동으로 샘플 페이지를 만드는 대신 바로 작업을 시작할 수 있도록 일부 게시물과 해당 번역을 자동으로 채우는 설정 스크립트가 있습니다.

페이지 구조는 다음과 같습니다:-

HomePage ==> BlogIndexPage ==> BlogPage

설정 스크립트는 다음을 수행합니다.-

• 루트 관리자 사용자를 생성합니다. 이를 사용자 One이라고 부르겠습니다.
• 홈페이지 인스턴스 생성
• 홈페이지를 새 루트 페이지로 연결
• 홈페이지 일본어 번역 만들기
• BlogIndexPage 인스턴스 생성
• BlogPage를 샘플 게시물로 채우고 BlogIndexPage 아래에 첨부합니다.
• include_subtree=True를 사용하여 BlogIndexPage 번역

이 모든 것은 페이지 구조가 다음과 같은 새 사이트를 설정할 때까지 잘 작동합니다.-

BlogIndexPage ==> BlogPage

그래서 이 사이트는 주로 블로그이므로 HomePage(지금은 좋지 않은 생각이지만 다른 주제를 위해 저장해 두겠습니다)를 생략했습니다. 설정 스크립트를 실행한 후 가장 먼저 눈에 띄는 것은 BlogIndexPage를 번역할 때 이미 include_subtree를 전달했음에도 불구하고 생성된 블로그 게시물의 번역이 없다는 것입니다.

내 첫 직감 반응은 새로운 할미새 버전에 약간의 변화가 있을 수 있다는 것이었습니다. 대부분의 사이트는 몇 년 전에 생성되었으며 여전히 wagtail 5에 있지만 이 새 사이트의 경우 최신 버전이므로 wagtail 6부터 시작하겠습니다.

그러나 simple_translation views.py에 대한 wagtail의 커밋 로그를 살펴보면 코드 마지막 변경 사항은 3년 전입니다. 그리고 wagtail 5와 6이 기본적으로 동일한 코드를 볼 수 있습니다.

위의translate_page 함수의 문제점은 오류를 확인하지 않는다는 것입니다. 오류를 포착한다는 것은 일부 오류 문자열에 대한 요청의 응답을 구문 분석해야 함을 의미하기 때문입니다. 하지만 코드 흐름을 추적해 보면 양식이 검증되지 않아 코드가 실행되지 않는 것을 볼 수 있습니다.

form.errors 인쇄 시 잘못된 로케일과 관련된 오류 메시지가 표시되었습니다. 위의 Translate_page 함수에서 아직 존재하지 않는 로캘을 생성하는 것을 볼 수 있기 때문에 이것은 이상합니다.

그리고 양식의 self.fields["locales"].choices를 인쇄하면 루트 페이지를 번역할 때 Translate_page()를 처음 호출하는 동안 선택 항목에 로캘이 있을 수 있지만 두 번째로 호출할 때는 선택 항목이 비어 있었습니다. BlogIndexPage를 번역합니다.

양식 코드를 읽으면 로캘 필드의 선택 사항이 __init__ 메서드에서 동적으로 설정됩니다. 여기서 이미 번역된 페이지의 로캘은 제거됩니다. 이것이 두 번째 호출에서 로케일이 비어 있는 이유일 수 있습니다. 하지만 페이지는 아직 번역되지 않았습니다!

프로세스를 다시 떠올려 보겠습니다.-

• 블로그 인덱스페이지 만들기
• BlogIndexPage를 루트 페이지에 연결
• 루트 페이지를 ja로 번역
• BlogPage를 채워 BlogIndexPage에 첨부
• BlogIndexPage를 ja로 번역

그리고 몇 시간의 디버깅 끝에 전구(?)가 등장한 곳입니다. 원래 스크립트에서는 HomePage를 먼저 ja로 변환한 다음 BlogIndexPage를 모든 하위 항목과 함께 변환합니다. 하지만 이 새 스크립트에서 루트 페이지는 BlogIndexPage입니다. 따라서 BlogIndexPage는 두 번째로translate_page를 호출할 때 이미 번역되었습니다!

이것이 로케일 선택이 비어 있는 이유입니다.