Я не могу найти программный интерфейс для создания перевода страниц. Кажется, вся логика реализована в SubmitTranslationView в 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

И сценарий установки выполнит следующее: -

• Создайте пользователя root-admin, назовем его пользователем One.
• Создать экземпляр домашней страницы
• Прикрепить домашнюю страницу как новую корневую страницу
• Создать японский перевод домашней страницы
• Создать экземпляр BlogIndexPage
• Заполните BlogPage образцами сообщений и прикрепите их к BlogIndexPage
• Перевести BlogIndexPage с помощью include_subtree=True

Все это работает хорошо, пока мы не настроим новый сайт со следующей структурой страниц: -

BlogIndexPage ==> BlogPage

Поэтому мы опустили Домашнюю страницу (что сейчас кажется плохой идеей, но давайте оставим ее для другой темы), поскольку этот сайт в основном представляет собой блог. Первое, что я заметил после запуска сценария установки, это отсутствие перевода сообщений в блоге, несмотря на то, что мы уже передали include_subtree при переводе BlogIndexPage.

Моей первой инстинктивной реакцией было то, что в новых версиях трясогузки могут быть некоторые изменения. Большинство наших сайтов созданы несколько лет назад и до сих пор работают на версии трясогузки 5, но для этого нового сайта мы начнем с версии 6, так как она самая последняя.

Но, судя по журналам коммитов wagtail для simple_translationviews.py, последние изменения в коде были три года назад. И мы видим, что код практически одинаков для трясогузки 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!

Так вот почему выбор локалей становится пустым.