Wagtail 以程式設計方式建立頁面翻譯

我找不到任何程式設計介面來建立頁面翻譯。所有邏輯似乎都在 wagtail.contrib.simple_translation.views 的 SubmitTranslationView 中實作。

因此，以程式設計方式存取這些內容的唯一方法是模擬存取視圖的請求。我將其包裝在一個名為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

安裝腳本將執行以下操作：-

• 建立 root 管理員用戶，我們稱之為用戶 One。
• 建立主頁實例
• 附加首頁作為新的根頁
• 建立主頁的日文翻譯
• 建立 BlogIndexPage 的實例
• 使用範例貼文填入 BlogPage 並將其附加到 BlogIndexPage
• 使用 include_subtree=True 翻譯 BlogIndexPage

這一切都運作良好，直到我們設定頁面結構為的新網站：-

BlogIndexPage ==> BlogPage

所以我們省略了主頁（我現在認為這是一個壞主意，但讓我們將其保存到另一個主題），因為這個網站主要是一個博客。運行設定腳本後我注意到的第一件事是沒有建立部落格文章的翻譯，儘管我們在翻譯 BlogIndexPage 時已經傳遞了 include_subtree。

我的第一個直覺反應是新的鶺鴒版本可能會發生一些變化。我們的大多數網站都是幾年前創建的，仍然使用 wagtail 5，但對於這個新網站，我們將從 wagtail 6 開始，因為它是最新的。

但查看 wagtail 的 simple_translationviews.py 提交日誌，程式碼最後一次變更是在三年前。我們可以看到 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 及其所有子項轉換為 ja。但在這個新腳本中，根頁面是 BlogIndexPage。所以當我們第二次呼叫translate_page時BlogIndexPage已經翻譯了！

這就是區域設定選擇變成空的原因。

以上是Wagtail 以程式設計方式建立頁面翻譯的詳細內容。更多資訊請關注PHP中文網其他相關文章！