Wagtail crée par programme une traduction de page

Je ne trouve aucune interface de programmation pour créer une traduction de page. Toutes les logiques semblent être implémentées dans SubmitTranslationView dans wagtail.contrib.simple_translation.views.

Donc, la seule façon d'y accéder par programmation est de simuler la demande d'accès aux vues. J'ai enveloppé cela dans une fonction nommée Translate_page(). Pour traduire une page, nous pouvons appeler cette fonction comme :-

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

Ou on peut passer le paramètre facultatif include_subtree:-

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

Et la fonction est définie comme :-

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

J'ai une autre fonction appelée Translate_snippet(). La seule différence est simplement l'URL à soumettre et l'absence de paramètre include_subtree.

Les pièges de l'arbre des pages

Pour tous nos sites, nous disposons d'un script de configuration qui remplira automatiquement certains articles et leur traduction afin que le développeur puisse commencer à travailler immédiatement au lieu d'avoir à créer des exemples de pages manuellement.

La structure de nos pages est la suivante :-

HomePage ==> BlogIndexPage ==> BlogPage

Et le script de configuration fera ce qui suit :-

• Créez l'utilisateur administrateur root, appelons-le utilisateur Un.
• Créer une instance de page d'accueil
• Joindre la page d'accueil en tant que nouvelle page racine
• Créer une traduction japonaise de la page d'accueil
• Créer une instance de BlogIndexPage
• Remplissez la page Blog avec des exemples d'articles et joignez-les sous BlogIndexPage
• Traduisez BlogIndexPage avec include_subtree=True

Tout cela fonctionne bien jusqu'à ce que nous définissions un nouveau site où la structure des pages est :-

BlogIndexPage ==> BlogPage

Nous avons donc omis la page d'accueil (ce qui, je pense, est une mauvaise idée maintenant mais gardons-la pour un autre sujet) puisque ce site est principalement un blog. La première chose que je remarque après avoir exécuté le script de configuration est qu'aucune traduction des articles de blog n'est créée, bien que nous ayons déjà transmis include_subtree lors de la traduction de BlogIndexPage.

Ma première réaction instinctive a été qu'il pourrait y avoir des changements dans les nouvelles versions de bergeronnette. La plupart de nos sites ont été créés il y a quelques années et toujours sur wagtail 5 mais pour ce nouveau site, nous commencerons par wagtail 6 puisque c'est le dernier en date.

Mais en regardant les journaux de validation de wagtail pour simple_translation vues.py, les dernières modifications du code remontent à trois ans. Et nous pouvons voir le code fondamentalement le même entre bergeronnette 5 et 6.

Le problème avec la fonction Translate_page ci-dessus est qu'elle ne vérifie aucune erreur. Parce que la détection des erreurs signifie que vous devez analyser la réponse de la requête pour rechercher une chaîne d'erreur. Mais suivre le flux du code m'a conduit à une étape où je peux voir que le code n'est pas exécuté car le formulaire n'est pas validé.

L'impression du formulaire.errors a affiché des messages d'erreur liés à des paramètres régionaux non valides. C'est étrange car nous pouvons voir dans la fonction translate_page ci-dessus que nous créons la locale si elle n'existe pas encore.

Et en imprimant les choix self.fields["locales"] du formulaire, je peux, les paramètres régionaux sont là dans le choix lors du premier appel de translate_page() lors de la traduction de la page racine, mais les choix étaient vides lors de son deuxième appel à traduire BlogIndexPage.

En lisant le code du formulaire, les choix du champ locales sont définis dynamiquement dans la méthode __init__, où les paramètres régionaux de la page déjà traduite seront supprimés. Cela pourrait être la raison pour laquelle les paramètres régionaux étaient vides lors du deuxième appel. Mais la page n'est pas encore traduite !

Rappelons le processus :-

• Créer une page d'index de blog
• Attacher BlogIndexPage à la page racine
• Traduire la page racine en ja
• Remplissez BlogPage et joignez-les à BlogIndexPage
• Traduire BlogIndexPage en ja

Et c'est là que l'ampoule (?) est entrée en jeu, après des heures de débogage. Dans le script original, nous traduisons d'abord HomePage en ja, puis BlogIndexPage avec tous ses enfants. Mais dans ce nouveau script, la page racine est BlogIndexPage. BlogIndexPage a donc déjà été traduit la deuxième fois que nous appelons Translate_page !

C'est donc la raison pour laquelle les choix de paramètres régionaux deviennent vides.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!