Ingo Steinke (openmindculture)

Okay, so last chance to take screenshots of funny Google translation fails before the fix. Thanks @vmarko !

Hi @stefan44 , for a workaround see https://www.ads-software.com/support/topic/german-verschlimmbesserung/#post-16285373

Yeah, they even translated their manufacturer name (BoldGrid) to “FettGitter” (“greasy grid”) ??</img>?

Reply and mark as resolved

Thanks @vmarko ! I must have overlooked the General page, or it might have temporarily vanished before deleting the incomplete German plugin translations.

I can confirm that deleting the translation files brings back the English text, which is a good workaround so far.

I noticed some failed translations, even funny somehow, where it simply makes no sense: “Reverse-Proxy-Caching über Lack aktivieren” translates “varnish” literally to “Lack” while this is a trademark / product name (“Varnish cache”) that should not be translated, at least in my opinion.

Does it help if I add some more specific examples and suggested translations? You could also add me as a German translator to W3C project if you like. I am glad if I can help!

Before crashing my customer’s WooCommerce shop again, like I asked in the support post, is it safe to use after the update now? Because the reported versions were definitely NOT COMPATIBLE in reality, as they resulted in a fatal error message caused by MailPoet, which prevented our customers to proceed with the checkout!

Is this error supposed to be fixed in MailPoet 4.1.1 / WooCommerce 7.1.1?
Is it safe to try again?

Is this error supposed to be fixed in MailPoet 4.1.1 / WooCommerce 7.1.1?
Is it safe to try again?

Thanks for your quick reply, @diego373 ! We will try if it works.

I have a similar problem. The checkout page uses WooCommerce block syntax, and PayPal Payment is not showing up as an option.

See this GitHub issue by dovidhub, unfortunately not answered yet, which might have the same root cause as the problem described here:

PayPal Payments Not Working With New WooCommerce Checkout Blox

Danke für die ausführliche Beratung! Die rechtlichen Fragen sollen die Shopbetreiber:innen gerne selbst kl?ren, das habe ich entsprechend weitergeleitet. Das Zusammenlegen der Tabs finde ich dennoch interessant und schaue mir die verlinkte Dokumentation gerne an.

Den Hinweis auf das Help Desk habe ich auch gesehen und vermerkt.

Ich habe unsere Diskussion übrigens auch hier verlinkt, wo ich den gleichen Rat (weiter)gebe (nicht nur von euch, sondern auch von Jessica neulich am Rande eines Meetups) lieber noch zu warten, anstelle jetzt schon voll auf Block Themes zu setzen:

https://dev.to/ingosteinke/should-we-use-woocommerce-block-theme-syntax-in-2022-4n61

This problem has been resolved by using the [product] shortcode instead of <!-- wp:woocommerce/all-products, which is a workaround than a solution, but at least this works in our theme now!

Thanks to the Germanized for WooCommerce plugin support team for pointing me in the right direction! See
– [Grundpreis fehlt auf Produktarchivseite](https://www.ads-software.com/support/topic/grundpreis-fehlt-auf-produktarchivseite/#post-16120916) (in German)
– [Should we use WooCommerce Block Theme Syntax in 2022?](https://dev.to/ingosteinke/should-we-use-woocommerce-block-theme-syntax-in-2022-4n61)

P.S. Hinweis: [products] produziert leider anderes Markup als <!-- wp:woocommerce/all-products, nicht nur andere Klassennamen sondern auch teilweise fehlende Wrapper etc. Das nachtr?glich umzustellen nervt, daher mein Praxistipp an alle Entwickler:innen 2022 noch auf die altbew?hrte Syntax zu setzen, um doppelte Arbeit zu vermeiden.

I resolved this problem by replacing the block code (Gutenberg) syntax (<!-- wp:woocommerce/all-products) with traditional shortcode notation ([products]) in our product archive template (archive-product.html).

Explanation: the new syntax (wp:woocommerce) triggers a JavaScript function that loads the product grid on the client side, so the traditional PHP hooks used by many current plugins, are not triggered! The shortcode syntax makes use of the traditional PHP way, which also has the advantage to generate the complete markup before sending the page to the client browser, which could be a benefit for client-side caching, reverse proxy / content delivery network caching, and search engine optimization (SEO) as well.

Anyway, thanks to the WooCommerce Germanized plugin support for pointing out the difference! See this German WordPress support issue that brought me to the solution: https://www.ads-software.com/support/topic/grundpreis-fehlt-auf-produktarchivseite/#post-16118802

This workaround resolves the problem on my behalf, although this and other plugins currently still don’t work when we use the block syntax, which will be used by more and more users when WordPress keeps rolling out full site editing and making block themes the new default.

Ich habe parallel selbst recherchiert. Shortcode ist m?glich, und dann sind auch Grundpreise zu sehen! Styling muss ich noch nachziehen, scheinbar ist das Markup nicht identisch oder ein Class Name verloren gegangen.

Jedenfalls ist der [products] Shortcode grunds?tzlich ein Ersatz für <!-- wp:woocommerce/all-products, der auch in Block Templates (.html) funktioniert.

Beispiel:

[products columns="5" rows="2" orderby="date" limit="8" class="alignwide wc-block-all-products"]

Da ich ohnehin kein Freund unn?tiger JavaScript-Nutzung bin, ist das konkrete Problem für micht hiermit gel?st. Allerdings ist es eigentlich nur ein Workaround, und wenn ich die WordPress-Community richtig verstehe, soll es ja in Zukunft noch mehr in Richtung Full Site Editing (FSE) mit Gutenberg gehen, daher w?re es langfristig wünschenswert, Germanized entsprechend zu erweitern.

• This reply was modified 2 years, 5 months ago by Ingo Steinke (openmindculture). Reason: Reply and mark as resolved