How to Sell Multi-Language Event Tickets in WordPress (Cyrillic Included)

You set up your event, sell your first tickets, and then a screenshot arrives from an attendee: the name on their PDF ticket reads “□□□□□” instead of “Милица Јовановић”. Anyone selling tickets to an audience that writes in Cyrillic, Greek, or any script beyond basic Latin has either hit this problem or is about to. Tofu boxes on tickets, half-translated checkout pages, and event dates rendered in the wrong language all make an otherwise professional event look careless — and they generate support emails at the worst possible time, right before doors open.

The good news: WordPress itself is thoroughly multilingual, and if your ticketing runs on WooCommerce the hardest parts are already solved for you. This guide walks through selling event tickets in more than one language — with a special focus on getting non-Latin scripts like Cyrillic to render correctly on the ticket PDF itself, which is where most ticketing setups quietly fail.

Why ticket PDFs break with non-Latin text

Web pages rarely have this problem anymore. Your theme loads a web font, the browser falls back to system fonts for missing characters, and Cyrillic “just works.” PDFs are different: a PDF ticket embeds specific fonts, and if the embedded font has no glyph for the character being printed, the reader shows blanks or tofu boxes. There is no automatic system-font fallback inside a PDF.

This matters most for the fields you don’t control: attendee names. You can write your event title in whichever language you like, but buyers type their names in their own script. A ticket template that looks flawless with “John Smith” can fall apart the moment “Дмитрий” buys a ticket — unless the PDF generator detects the script and handles it.

How Venuera handles Cyrillic and Unicode on tickets

Venuera’s Ticket Designer add-on was built with this failure mode in mind, and it is worth understanding the mechanics because they differ from most PDF plugins:

The editor and the PDF use the same font files

The font library bundles 21 font families, and the exact same TTF files power both the on-screen editor (via @font-face) and the PDF generator (via embedding). What you see while designing is what prints — there is no “web font in the editor, different PDF font at render time” mismatch.

Many bundled families include Cyrillic glyphs natively

Families such as Montserrat, Oswald, Raleway, Nunito, Ubuntu, Merriweather, Playfair Display, Lora, PT Serif, Caveat and Lobster ship with Cyrillic coverage. If you design your ticket in one of these, Cyrillic event titles, venue names and attendee names print in the same typeface as everything else.

Real glyph-coverage detection, not guesswork

Some fonts are Latin-only by design — decorative display faces like Bebas Neue or Pacifico simply don’t contain Cyrillic glyphs. When Venuera generates a PDF, it inspects the font’s actual glyph coverage against the text being printed. Ordinary typographic characters like em dashes, curly quotes or ellipses stay in your chosen font, but if a glyph is genuinely missing — Cyrillic text in a Latin-only face — that element falls back to a bundled DejaVu Unicode font (sans or serif, matched to your font’s category) instead of printing blanks. Classic core fonts like Arial or Times get the same treatment: text that needs Unicode is switched to DejaVu automatically.

The practical takeaway: pick a Cyrillic-capable family for name and free-text fields if your audience uses Cyrillic, and let the fallback act as a safety net rather than the main path. Our guide to designing professional event tickets covers the design side in more depth.

Translating the rest of the buying journey

A correct PDF is half the job. Attendees also see your event page, checkout, order emails and the ticket email. Here is how the pieces fit together on WordPress.

1. Set the site language (or add a second one)

WordPress ships in over a hundred languages. For a single-language shop, Settings → General → Site Language switches core, and translated plugins follow. Venuera is translation-ready in the standard WordPress way: it declares a text domain and ships a POT template covering its user-facing strings, so tools like Loco Translate or Poedit can produce a translation for any locale — no code edits required.

2. WooCommerce handles currency, checkout and emails

Because Venuera tickets are ordinary WooCommerce products, everything WooCommerce already localizes applies to tickets too: checkout field labels, order emails, currency formatting and tax display. WooCommerce itself is translated into dozens of languages, and for a fully multilingual store (two or more languages running side by side) the established WordPress multilingual plugins that integrate with WooCommerce treat ticket products like any other product. There is no separate “ticketing translation layer” to fight with.

3. Collect attendee details in any script

If you collect each attendee’s name at checkout — which you should for personalized tickets — those fields accept whatever the buyer types, in any script. The custom attendee fields guide shows how to set this up; the Ticket Designer supports nine attendee field types you can place directly on the ticket layout, and the Unicode handling described above applies to all of them.

4. Keep your structured data consistent

Venuera outputs Schema.org Event markup on event pages, which is how your events become eligible for Google’s event rich results. If you run pages in multiple languages, keep each page’s markup in that page’s language — Google reads the markup per URL. See our walkthrough on event schema markup in WordPress for the details.

A practical setup checklist

For a bilingual event site — say Serbian and English — a sensible order of operations looks like this. First, install WordPress in your primary language and confirm WooCommerce checkout strings appear translated. Second, create your ticket products and event, writing titles and descriptions in your primary language. Third, open the Ticket Designer and build your template with a Cyrillic-capable family (PT Serif and Montserrat are safe, versatile choices) for any field that will carry attendee input. Fourth, place a test order using a Cyrillic name and open the PDF — this two-minute test catches ninety percent of localization problems before any real buyer does. Fifth, if you need both languages live simultaneously, add a multilingual plugin and translate the event page and product descriptions; the ticket template itself doesn’t need duplicating, since it prints whatever the order and event data contain.

One more detail organizers often forget: dates. “March 5” reads as “5. март” to a Serbian buyer. WordPress date functions localize month and day names automatically when the locale is set correctly, so fixing the site language usually fixes the dates everywhere they appear.

Why self-hosted helps here

Hosted ticketing platforms decide which languages, scripts and fonts you get. On your own WordPress site, you control the full stack — fonts on the PDF, strings at checkout, currency, date formats — and none of it costs per-ticket fees. Venuera’s core plugin is free with no per-ticket fee, and the Ticket Designer add-on that provides the font library and PDF control is part of the paid add-on lineup.

Frequently asked questions

Do Venuera ticket PDFs support Cyrillic text?

Yes. Many of the 21 bundled font families include Cyrillic glyphs natively, and when a chosen font lacks a needed glyph, the PDF generator automatically falls back to a bundled DejaVu Unicode font so names and titles never print as blank boxes.

Can I translate the Venuera plugin into my language?

Yes. Venuera is translation-ready in the standard WordPress way: it ships a POT template, so you can create a translation for any locale with tools like Loco Translate or Poedit without touching code.

Will attendee names in non-Latin scripts appear on tickets?

Yes. Attendee fields accept any script the buyer types, and the ticket PDF renders them using a font with the right glyph coverage — either your chosen Cyrillic-capable family or an automatic Unicode fallback.

Do I need a multilingual plugin to sell tickets in one non-English language?

No. For a single language, setting the WordPress site language and translating plugin strings is enough. Multilingual plugins are only needed when you want two or more languages running side by side on the same site.