Ich kann keine programmatische Schnittstelle zum Erstellen einer Seitenübersetzung finden. Die gesamte Logik scheint in SubmitTranslationView in wagtail.contrib.simple_translation.views implementiert zu sein.

Die einzige Möglichkeit, programmgesteuert auf diese zuzugreifen, besteht darin, die Anforderung zum Zugriff auf die Ansichten zu simulieren. Ich habe dies in eine Funktion namens Translate_page() verpackt. Um eine Seite zu übersetzen, können wir diese Funktion wie folgt aufrufen:-

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

Oder wir können den optionalen Parameter include_subtree:-
übergeben

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

Und die Funktion ist definiert als:-

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

Ich habe eine andere Funktion namens Translate_snippet(). Der einzige Unterschied besteht nur in der zu übermittelnden URL und im fehlenden include_subtree-Parameter.

Fallstricke im Seitenbaum

Für alle unsere Websites verfügen wir über ein Setup-Skript, das einige Beiträge und deren Übersetzung automatisch ausfüllt, sodass Entwickler sofort mit der Arbeit beginnen können, anstatt Beispielseiten manuell erstellen zu müssen.

Unsere Seitenstruktur sieht so aus:-

HomePage ==> BlogIndexPage ==> BlogPage

Und das Setup-Skript führt Folgendes aus:-

• Erstellen Sie den Root-Administratorbenutzer, nennen wir ihn Benutzer Eins.
• Instanz von HomePage erstellen
• HomePage als neue Stammseite anhängen
• Erstellen Sie eine japanische Übersetzung der Startseite
• Instanz von BlogIndexPage erstellen
• BlogPage mit Beispielbeiträgen füllen und diese unter BlogIndexPage anhängen
• BlogIndexPage mit include_subtree=True übersetzen

Das funktioniert alles gut, bis wir eine neue Website einrichten, deren Seitenstruktur wie folgt lautet:-

BlogIndexPage ==> BlogPage

Also haben wir HomePage weggelassen (was ich jetzt für eine schlechte Idee halte, aber heben wir es uns für ein anderes Thema auf), da es sich bei dieser Seite hauptsächlich um einen Blog handelt. Das erste, was mir nach dem Ausführen des Setup-Skripts auffällt, ist, dass keine Übersetzung der erstellten Blogbeiträge erfolgt, obwohl wir bei der Übersetzung von BlogIndexPage bereits include_subtree übergeben haben.

Meine erste Bauchreaktion war, dass es bei den neuen Bachstelzenversionen einige Änderungen geben könnte. Die meisten unserer Websites wurden vor einigen Jahren erstellt und basieren immer noch auf Bachstelze 5, aber für diese neue Website beginnen wir mit Bachstelze 6, da es die neueste ist.

Aber ein Blick auf die Commit-Protokolle von Wagtail für simple_translation views.py zeigt, dass die letzten Änderungen am Code drei Jahre her sind. Und wir können sehen, dass der Code zwischen Bachstelze 5 und 6 im Grunde derselbe ist.

Das Problem mit der oben genannten Funktion „translate_page“ besteht darin, dass sie nicht nach Fehlern sucht. Denn das Abfangen von Fehlern bedeutet, dass Sie die Antwort der Anfrage auf eine Fehlerzeichenfolge analysieren müssen. Aber die Verfolgung des Codeflusses führte mich zu einem Punkt, an dem ich sehen konnte, dass der Code nicht ausgeführt wurde, weil das Formular nicht validiert wurde.

Beim Drucken von form.errors wurden Fehlermeldungen im Zusammenhang mit einem ungültigen Gebietsschema angezeigt. Das ist seltsam, weil wir in der obigen Funktion Translate_page sehen können, dass wir das Gebietsschema erstellen, wenn es noch nicht existiert.

Und beim Drucken der self.fields["locales"].choices des Formulars kann ich erkennen, dass das Gebietsschema beim ersten Aufruf von Translate_page() beim Übersetzen der Stammseite in der Auswahl vorhanden ist, aber die Auswahlmöglichkeiten waren beim zweiten Aufruf leer BlogIndexPage übersetzen.

Beim Lesen des Codes des Formulars werden die Auswahlmöglichkeiten des Gebietsschemafelds dynamisch in der Methode __init__ festgelegt, wobei das Gebietsschema der bereits übersetzten Seite entfernt wird. Dies könnte der Grund dafür sein, dass das Gebietsschema beim zweiten Aufruf leer war. Aber die Seite ist noch nicht übersetzt!

Erinnern wir uns noch einmal an den Vorgang:-

• BlogIndexSeite erstellen
• BlogIndexPage an Stammseite anhängen
• Stammseite in ja übersetzen
• BlogPage füllen und an BlogIndexPage anhängen
• BlogIndexPage in ja übersetzen

Und hier kam nach stundenlangem Debuggen die Glühbirne (?) ins Spiel. Im ursprünglichen Skript übersetzen wir zuerst „HomePage“ in „ja“ und dann „BlogIndexPage“ mit all seinen untergeordneten Elementen. Aber in diesem neuen Skript ist die Stammseite BlogIndexPage. BlogIndexPage wurde also bereits beim zweiten Aufruf von Translate_page übersetzt!

Das ist also der Grund, warum die Auswahl der Gebietsschemas leer wird.