Cart Labels

When a discount applies, it shows up in the customer's cart as a line item with a label — "Spend & Save: 10% off", "Bulk pricing: 5+ at £8 each", and so on. The label is editable from the Messaging section at the bottom of the rule editor, with the same token grammar the storefront uses at render time.

Where to edit the cart label

Scroll to the Messaging section at the bottom of the rule editor (after Rewards). The first sub-block, Cart label, is a single-line text input — always editable, with no structural lock. Type whatever you want shoppers to see; leave it blank and Dino falls back to "Discount."

The Plain English summary green box above the Rewards section also reads the cart label back as part of the sentence describing what your rule does — so if the label reads wrong in plain English, it'll read wrong in the cart.

Token grammar

The input accepts three substitution tokens that the storefront swaps in at render time:

| Token | Meaning | Example output | |-------|---------|----------------| | [ccy] | Cart currency symbol (matches the customer's checkout currency) | [ccy]10 Off → "£10 Off" / "€10 Off" / "$10 Off" | | [X] | Discount value (the primary number from the rule — percent or amount) | [X]% off → "15% off" | | [Y] | Secondary value (for two-number rules like buy-N-get-M) | Buy [X] get [Y] → "Buy 3 get 1" |

The tokens are substituted by the engine (AbstractStrategy::replace_placeholders) at the same time the cart line renders. Tokens that don't apply to the rule shape stay literal — [Y] on a single-percentage rule renders as [Y], so don't leave it in unless you mean it.

The token grammar is the reason the same rule can render correctly in a multi-currency store without re-saving: [ccy]10 Off is one string that renders as "£10 Off" or "€10 Off" depending on the shopper's checkout currency. See Multi-currency for how prices and labels stay matched per checkout currency.

When the input is blank

If you leave the cart-label input empty, Dino renders the localised string "Discount" at cart time — never the internal coupon code. That's the only auto-fallback: there is no per-discount-type label generator.

Recipes typically seed the input with a sensible starting string when you pick them from the gallery (e.g. [ccy][X] Off) — that string is editable as soon as the rule opens, and you can clear it to fall back to "Discount" any time.

Multilingual stores

Admin-entered strings — the Cart label, the Spend-more nudge message, the Custom message on the product page, and the rule's own Name — are stored in the database as the literal text you typed. They do not flow through WordPress's .pot/__() translation pipeline that the plugin's own UI strings use, so a single rule shows the same label to every shopper regardless of their site language.

Enter labels in the language your store actually serves. For a single-locale store this is straightforward — type the copy in the storefront's language and you're done.

For a multilingual store, model each language as a separate rule and use Zone targeting (in the rule editor's Where does it apply? section) to scope each one to the right region:

• Rule A — cart_label = "Réduction", scoped to a "France" zone.
• Rule B — cart_label = "Discount", scoped to a "UK & US" zone.
• Rule C — cart_label = "Rabatt", scoped to a "Germany" zone.

The engine evaluates Zone targeting per shopper, so each one sees only the rule whose zone matches their country — and therefore only the language-appropriate label. The same per-rule split applies to the spend-more nudge, the product-page custom message, and the rule name.

The token grammar above ([ccy], [X], [Y]) is locale-neutral and substitutes the same way regardless of language, so a French rule can still write Réduction [ccy][X] and have [ccy] resolve to "€" automatically.

Why not just translate the stored string?

Admin-entered strings are merchant input, not plugin output — there is no upstream English source for a translator to render into a target locale. A .pot-driven workflow would require us to round-trip every merchant edit through a translation file, which is the opposite of the "edit-and-publish" feedback loop the rule editor is designed for. The per-zone-rule pattern keeps the merchant in direct control of every shopper-facing string.

Aliases and legacy data

Rules saved before the Messaging section landed used two older field names — cart_name and block_cart_chip. The editor reads through getCartLabel(), which falls back through both legacy fields, so legacy rules render their merchant-authored copy in the new UI without a forced re-save. The editor only ever writes the canonical cart_label field, so on next save the legacy alias values are superseded.

You can hit the same field from the REST API for bulk imports — see the REST API reference for the cart_label field and the corresponding alias columns.

Tips

• Keep it short. The cart line is usually narrow on mobile — "Loyalty 10% off" reads better than "VIP / Member exclusive 10% off the cart."
• Use [ccy] for amount-based labels. It saves you a separate rule per currency.
• Don't include the price — Dino renders the discount amount on its own column. The label is for the reason ("Spend & Save"), not the number.
• Match the language to the recipe. The Plain English summary in the editor is a good gut-check — if the summary reads strangely with your label, so will the cart.

What's next

• Upsell Messages — the spend-more nudge editor lives in the same Messaging section
• Product Page Pricing — the product-page block lives in the same Messaging section
• Testing with Cart Preview — verify the label renders the way you expect before publishing