New to Translating WordPress? Read through our Translator Handbook to get started. Hide
| Prio | Original string | Translation | — |
|---|---|---|---|
| ↑ | Free, complete EU Directive 2023/2673 toolkit: withdrawal button, checkout consents, Annex I.B form, Article 16 exclusions, SHA-256 proof. | You have to log in to add a translation. | Details |
Original untranslated
Free, complete EU Directive 2023/2673 toolkit: withdrawal button, checkout consents, Annex I.B form, Article 16 exclusions, SHA-256 proof.
You have to log in to edit this translation. |
|||
| ↑ | EU Withdrawal Compliance | You have to log in to add a translation. | Details |
Original untranslated |
|||
| Yes. The withdrawal status is set once, on the product (or category) in the site original language, and applies to every translation: the excluded-product notice, the checkout consents and the excluded items recorded on the order all resolve back to the original, so nothing has to be flagged twice. An explicit status on a translation still wins, if you need a per-language exception. Links to the withdrawal page follow the visitor language whenever a translation of that page exists. The plugin also ships a <code>wpml-config.xml</code> file, read by WPML and Polylang alike, that turns the settings holding customer-facing copy (the excluded-product notice titles and bodies, the form intro, the consent texts, the trader address) into translatable strings under <strong>WPML → String Translation</strong> or <strong>Languages → Translations</strong>. A setting shows up there once you have written your own text in it: left empty, there is nothing to translate, because the text then comes from the language pack of each locale and already follows the language of the visitor. So you have both routes: leave a field empty and let the bundled translation do the work, or write your own text and translate it under String Translation. The texts bundled with the plugin need no configuration. | You have to log in to add a translation. | Details | |
Original untranslated
Yes. The withdrawal status is set once, on the product (or category) in the site original language, and applies to every translation: the excluded-product notice, the checkout consents and the excluded items recorded on the order all resolve back to the original, so nothing has to be flagged twice. An explicit status on a translation still wins, if you need a per-language exception. Links to the withdrawal page follow the visitor language whenever a translation of that page exists. The plugin also ships a <code>wpml-config.xml</code> file, read by WPML and Polylang alike, that turns the settings holding customer-facing copy (the excluded-product notice titles and bodies, the form intro, the consent texts, the trader address) into translatable strings under <strong>WPML → String Translation</strong> or <strong>Languages → Translations</strong>. A setting shows up there once you have written your own text in it: left empty, there is nothing to translate, because the text then comes from the language pack of each locale and already follows the language of the visitor. So you have both routes: leave a field empty and let the bundled translation do the work, or write your own text and translate it under String Translation. The texts bundled with the plugin need no configuration.
CommentFound in faq paragraph. You have to log in to edit this translation. |
|||
| One current limitation worth knowing: the plugin's own emails (acknowledgement of receipt, admin notification and status changes) are composed in the site default language, not in the language the customer was browsing in, because they are generated outside the language routing of both plugins. The withdrawal notice injected into the WooCommerce transactional emails does follow the order language, since WooCommerce Multilingual and Polylang for WooCommerce switch the locale for those. Per-customer language for the plugin's own emails is on the roadmap. | You have to log in to add a translation. | Details | |
Original untranslated
One current limitation worth knowing: the plugin's own emails (acknowledgement of receipt, admin notification and status changes) are composed in the site default language, not in the language the customer was browsing in, because they are generated outside the language routing of both plugins. The withdrawal notice injected into the WooCommerce transactional emails does follow the order language, since WooCommerce Multilingual and Polylang for WooCommerce switch the locale for those. Per-customer language for the plugin's own emails is on the roadmap.
CommentFound in faq paragraph. You have to log in to edit this translation. |
|||
| The two-step flow required by Article 11a keeps the validated declaration on the server, in a 15-minute single-use transient, between the form and the review screen. When an object cache does not store transients reliably (a misconfigured Redis or Memcached drop-in, or a cache plugin flushing them aggressively) the declaration is already gone by the time the customer confirms, and the form asks them to start over. To confirm the cause, disable the object cache for a moment and submit again: if the flow completes, that was it. Transients are the standard WordPress mechanism for this, and the alternative (carrying the declaration in the URL or in hidden fields) would break the guarantee that what gets registered is exactly what was validated, so the fix belongs to the cache configuration. | You have to log in to add a translation. | Details | |
Original untranslated
The two-step flow required by Article 11a keeps the validated declaration on the server, in a 15-minute single-use transient, between the form and the review screen. When an object cache does not store transients reliably (a misconfigured Redis or Memcached drop-in, or a cache plugin flushing them aggressively) the declaration is already gone by the time the customer confirms, and the form asks them to start over. To confirm the cause, disable the object cache for a moment and submit again: if the flow completes, that was it. Transients are the standard WordPress mechanism for this, and the alternative (carrying the declaration in the URL or in hidden fields) would break the guarantee that what gets registered is exactly what was validated, so the fix belongs to the cache configuration.
CommentFound in faq paragraph. You have to log in to edit this translation. |
|||
| Does it work on multilingual sites (WPML, Polylang)? | You have to log in to add a translation. | Details | |
Original untranslated
Does it work on multilingual sites (WPML, Polylang)?
CommentFound in faq header. You have to log in to edit this translation. |
|||
| The form says the request is no longer awaiting confirmation, right after the customer submitted it. Why? | You have to log in to add a translation. | Details | |
Original untranslated
The form says the request is no longer awaiting confirmation, right after the customer submitted it. Why?
CommentFound in faq header. You have to log in to edit this translation. |
|||
| The plugin's own strings arrive as language packs per locale. See the FAQ for the current limitation on the plugin's emails. | You have to log in to add a translation. | Details | |
Original untranslated
The plugin's own strings arrive as language packs per locale. See the FAQ for the current limitation on the plugin's emails.
CommentFound in description paragraph. You have to log in to edit this translation. |
|||
| Compliance cannot depend on the language the customer was browsing in, so both plugins are supported natively, with nothing to configure: | You have to log in to add a translation. | Details | |
Original untranslated
Compliance cannot depend on the language the customer was browsing in, so both plugins are supported natively, with nothing to configure:
CommentFound in description paragraph. You have to log in to edit this translation. |
|||
| Gutenberg block and classic widget for the withdrawal link. | You have to log in to add a translation. | Details | |
Original untranslated
Gutenberg block and classic widget for the withdrawal link.
CommentFound in description list item. You have to log in to edit this translation. |
|||
| HTML email templates inheriting the WooCommerce email theme, and plugin emails composed in the customer's own language on multilingual stores. | You have to log in to add a translation. | Details | |
Original untranslated
HTML email templates inheriting the WooCommerce email theme, and plugin emails composed in the customer's own language on multilingual stores.
CommentFound in description list item. You have to log in to edit this translation. |
|||
| <strong>WooCommerce Checkout block support</strong> for the Art. 16(m) and Art. 14(4)(a) consents, for stores already migrated away from the classic checkout shortcode. | You have to log in to add a translation. | Details | |
Original untranslated
<strong>WooCommerce Checkout block support</strong> for the Art. 16(m) and Art. 14(4)(a) consents, for stores already migrated away from the classic checkout shortcode.
CommentFound in description list item. You have to log in to edit this translation. |
|||
| <strong>Maintained by a Spanish WordPress trainer with 20+ years on the platform</strong>: es_ES translation kept up to date by the author on the official WordPress.org translation platform, prompt replies on the WordPress.org support forum and an active roadmap of free improvements (classic widget, Gutenberg block, dashboard widget, custom WC order status and more — all free). | You have to log in to add a translation. | Details | |
Original untranslated
<strong>Maintained by a Spanish WordPress trainer with 20+ years on the platform</strong>: es_ES translation kept up to date by the author on the official WordPress.org translation platform, prompt replies on the WordPress.org support forum and an active roadmap of free improvements (classic widget, Gutenberg block, dashboard widget, custom WC order status and more — all free).
CommentFound in description list item. You have to log in to edit this translation. |
|||
| <strong>Real multilingual support (WPML, Polylang)</strong>: exclusions and checkout consents configured once hold across every translation, and your editable texts are translatable from String Translation. | You have to log in to add a translation. | Details | |
Original untranslated
<strong>Real multilingual support (WPML, Polylang)</strong>: exclusions and checkout consents configured once hold across every translation, and your editable texts are translatable from String Translation.
CommentFound in description list item. You have to log in to edit this translation. |
|||
| Translation-ready: Spanish (es_ES) and every other locale are delivered as language packs from <a href="https://translate.wordpress.org/projects/wp-plugins/eu-withdrawal-compliance/">translate.wordpress.org</a>, so they update on their own. Follows WordPress Coding Standards, fully escaped output and sanitized input, capability checks and nonces on every admin action. | You have to log in to add a translation. | Details | |
Original untranslated
Translation-ready: Spanish (es_ES) and every other locale are delivered as language packs from <a href="https://translate.wordpress.org/projects/wp-plugins/eu-withdrawal-compliance/">translate.wordpress.org</a>, so they update on their own. Follows WordPress Coding Standards, fully escaped output and sanitized input, capability checks and nonces on every admin action.
CommentFound in description list item. You have to log in to edit this translation. |
|||
Export as
Comment
Short description.