danke für deine Rückmeldung. Ich benutze weder ein Script-Optimierungs- noch ein Cache-Plugin. Alle Dateien sind unter woocommerce-germanized-pro/build/multilevel-checkout-blocks/ auffindbar.
Ich habe nun auch eine neue lokale Installation mit WordPress de-DE (6.8.2), WooCommerce (10.1.0), Germanized (3.20.1) und Germanized Pro (4.2.10) durchgeführt und sehe dasselbe Problem.
Ich habe zudem versucht, die Übersetzungen mit Loco Translate zu prüfen, wobei alles „okay“ aussieht. Ein erneutes Speichern/Synchronisieren mit Loco Translate löst das Problem leider nicht.
Mich würde es daher einfach interessieren wie es bei der Live-Demo aussieht. Leider weiß ich auch nicht mehr weiter, wie man das Problem weiter analysieren kann.
ich habe den Checkout-Block bereits gelöscht und neu hinzugefügt, allerdings ohne Erfolg. Bei einer Neuinstallation mit aktuellen Versionen von WordPress, WooCommerce und Germanized (Pro) tritt der Fehler bei mir leider ebenfalls auf. Wäre es möglich, die Online-Demo zu aktualisieren, um so umgebungsunabhängig prüfen zu können, ob der Fehler weiterhin besteht?
Dann läuft anscheinend die Online-Demo noch nicht mit der neuesten Version von Germanized Pro. Ich habe mir die Version 4.2.10 nun heruntergeladen und getestet. Leider hat allerdings die Multi-Step-Kasse immer noch Schwierigkeiten mit der Übersetzung:
Und das obwohl in der “.po” Datei die Übersetzung vorhanden ist: (z.b Back to cart)
ich habe gesehen, dass das Update v3.20.1 inzwischen veröffentlicht wurde. Ist mit diesem Update der Fix bereits enthalten? Leider tritt das Problem bei mir weiterhin auf.
Auf der Demoseite von Germanized erscheint leider eine Exception, sobald man die Shopseite aufruft.
Blocksy does not use a special custom search function. The live search in Blocksy is based on standard WordPress conventions and uses the WordPress REST API to deliver search results.
The issue may lie in the fact that TranslatePress does not make translated content (such as product titles) available through the WordPress REST API.
The search filter used by TranslatePress, which hooks into pre_get_posts and calls the trp_search_filter function from the class-search.php file, only applies to the “classic” WordPress search (i.e., when $query->is_search() is true). However, this does not make translated content available through the REST API, which is likely the root of the issue with REST-based live search.
die Standardsprache der Website ist Deutsch, weshalb auch die Produktinformationen auf der Rechnung immer auf Deutsch ausgegeben werden. Bei TranslatePress werden die Übersetzungen nur textbasiert beim Laden der Seite Übersetzt und keine eigenen Seiten oder Produkte erstellt (wie es z.B bei WPML ist). Somit fehlen die Übersetzungen, wenn die Rechnung generiert wird.
Aus diesem Grund ist es nur möglich, die Anzeige wie beim Produktnamen über den Sync Filter “storeabill_woo_order_item_line_item_order_item_meta_to_sync” zu Übersetzen. Ich habe es auch gerade getestet – mit dem Filter funktioniert es! 😀
Vielen Dank für die schnelle Hilfe und macht weiter so! 🙂
Es geht hier um den Text und Wert für die Eigenschaft des Produkts. Dieser soll in der Kundenrechnung (PDF) immer auf Englisch angezeigt werden und nicht auf der Standardsprache Deutsch.
Mit „Produktvarianten“ meinte ich daher ein variables WooCommerce-Produkt mit Eigenschaften. Die jeweils ausgewählte Eigenschaft des Produkts (bzw. ausgewählte Variante) wird nämlich sowohl im Warenkorb als auch in der Rechnung als Text angezeigt und soll auf Englisch sein.
Hier ein Beispiel zum Warenkorb bei eingestellter Sprache „Englisch“ mit ein Variables Produkt, welches die Eigenschaft “Theme” mit dem Wert “Coloring Box” hat. (Deutsch = Thema: Malbox).
Und hier ein Ausschnitt der Kundenrechnung (PDF):
Wie man sieht, ist der Produktname bereits übersetzt, aber es Fehlt der Name und Wert der Eigenschaft.
Hoffe es ist damit etwas verständlicher was gemeint ist 😀 Grüße
