How do you run a conference in more than one language?

By Donghui Qian (Milo)Updated 28 October 20266 min read

Short answer

Run one event with one inventory. Translate what people read — the site, ticket names, form labels and confirmation emails — and keep prices, stock, sale windows and the schedule in one place. Give each language its own public address and publish it when that translation is ready. Do not copy the event. A model can draft the first site and a translation; a person who reads that language confirms it before anything goes live.

Summarise with

The usual shortcut is to duplicate the event. English then sells six seats and Chinese sells six more, and a six-seat room is oversold. The other shortcut is a language toggle that only changes the buttons. The tickets, the confirmation and the badge still arrive in English.

This is the rule for deciding what to share and what to translate. It applies to any registration tool, ours included.

Two events is not two languages

A separate copy has its own stock. Selling on both pages is two checkouts against two counts. A language version — whatever your platform calls a child of the main event — reuses the same tickets and the same inventory, so a seat sold on either page comes out of the same pool.

example.txt

# A workshop with 6 seats

Copied events: English sells 6 + Chinese sells 6 = 12 names, 6 chairs

Shared inventory: 6 sold across both pages = 6 names, 6 chairs

Copy when you are actually running two events: different dates, different cities, or a different ticket set. Translate when it is the same event, read in another language.

Translate what people read

Prices, stock and sale times are edited once, on the main event, and every language uses them. The title, the page, the ticket names and the form labels are written separately for each language.

Keep once, on the main event	Translate, per language
Ticket types, prices, currency, inventory, sale windows	Ticket names and descriptions
Dates, time zone, registration mode	Event title, summary and page copy
The schedule itself — rooms, times, who is speaking	Form field labels, help text and option choices
The guest list — shared across languages	Confirmation and reminder emails

Ask your platform what happens to session titles. Many keep the agenda on the main event, so the programme appears in the original language on every version. If that is the case, say so on the page rather than promising a fully translated timetable. Names on badges are names — do not translate them. Speaker names usually stay as they are.

Adding a language does not mean a different price list. If you need to present another currency, that is a payments problem, not a translation problem.

One guest list, whichever language they used

Attendees and orders should show up together, regardless of which language page they used. The desk has one list. The scanner does not need to know whether someone arrived from the English page or the Chinese one.

Mail follows the language they booked in. Someone who registered on the Traditional Chinese page should get the confirmation, the reminder and a cancellation in Traditional Chinese — not a later broadcast that forgot and went out in English.

Staff the exception desk for the languages you sell. A volunteer who can only search in English will stall the lane the first time a badge name is written in Chinese.

Publish each language when that version is ready

Each language needs its own public address and its own draft or published state. Translating the text does not publish it. Put the English page live when English is done; hold the other page until a person who reads that language has walked the whole path.

If you add a ticket or a form field later, add it on the main event. The versions should inherit a slot for the translation. Filling English only and leaving the other pages with the original words is how a "Chinese" checkout still asks questions in English.

How search engines tell the versions apart

Each language needs a real URL of its own, not a toggle that leaves the address unchanged. Then each page should point to the others with hreflang tags, so search engines can show the matching language instead of treating the translations as duplicates. Google's notes on localized versions are the rule to follow (localized versions). The rest of what an event site needs so crawlers and AI assistants can read it is the event website SEO guide.

Where a model saves time

Drafting is slow. Checking facts is the part that still needs a person. The useful split:

Draft the first language once. A description, last year's page address, or a screenshot of a schedule or price table is enough for a model to propose the site, ticket names, form fields and agenda. Nothing should be created until you have read the draft.
Check the facts before you translate. Dates, venue, prices and who is speaking are where models mix last year with this year. Fix them on the main event. Translation copies whatever you leave standing.
Draft the other language as words, not as a second event. Paste the title, page copy, ticket names and form labels into a model and ask for that language. Keep prices, dates and stock out of the prompt so it cannot invent a different offer.
Have a person who reads that language walk the page. Simplified Chinese and Traditional Chinese are not the same text with different glyphs. A native pass is the publish gate, not a courtesy.
Publish that version yourself. A model can propose copy. It should not flip the event live.

On bagevent the AI assistant drafts an event and its website from a description, a link or a screenshot, and polishes copy in place. Every change waits for you to confirm. It does not create the other language versions for you. You add a language version on the main event, then translate the words — by hand, or from a draft the assistant helped write — and publish that version when it is ready.

On bagevent

The platform runs in three languages: English, Simplified Chinese and Traditional Chinese. Those are the three. You add a language version from the main event, one per language, and it starts as a draft. Each version has its own public page. Tickets, prices, inventory and the schedule stay on the main event and are read-only on the version, so both pages sell from the same stock. Attendees get their transactional emails in the language they booked in. Serving the event from your own domain is not available yet. The click-by-click path is in Multi-language events. A two-language example is the live demo at summit.bagevent.io.

What usually goes wrong

The event was copied. Two inventories, one room. The oversell shows up at the door, not at checkout.
Only the chrome was translated. Buttons say 简体; the ticket name, the form and the confirmation are still English.
Simplified was pasted as Traditional. Readers notice. Search engines may also treat the pages as near-duplicates.
The programme stayed in one language and nobody said so, so attendees expect every session title to match the page they booked on.
A later reminder went out in English to everyone. Mail has to follow the language of the order, including change notices and cancellation.
A model published the translation. Last year's date, or a price the model rounded, is now live in the second language.
The desk cannot search the other script. The exception lane needs someone who can read the names you sold.

Before you publish

There is one inventory, not two events.
Each language has its own URL and is still a draft until a native reader has finished it.
A test purchase on each language page produces mail in that language.
Ticket names and form labels are translated, not only the hero.
You have said, in public, whether session titles follow the page language or stay on the main event.
hreflang points the versions at each other.
The exception desk has a script in every language you sell.

Frequently asked questions

No, not if it is the same event. A copy has its own stock, so sales on both pages can oversell one room. Use a language version — or whatever your platform calls a child that shares tickets and inventory — and translate the words people read. Copy only when the dates, city or ticket set are actually different.

The title, page copy, ticket names and descriptions, form labels, help text, option choices, and the emails that follow the order. Prices, currency, inventory, sale windows, dates and the schedule itself stay on the main event. Session titles often stay in the original language; if yours do, say so. Do not translate names on badges.

They should follow the language of the page the person booked on: confirmation, reminders, change notices and cancellation. The guest list is still one list. A later broadcast that ignores the order language puts English in the inbox of someone who never saw English on the site.

It can draft. It should not publish. Use a model to draft the first-language site and then to draft the display text of the other language. A person who reads that language checks dates, prices and wording, especially Simplified versus Traditional Chinese, and you publish that version yourself. On bagevent the assistant does not create language versions in one step.

Each version needs its own URL. Each page should point to the others with hreflang tags so the translations are not treated as duplicates. A toggle that never changes the address cannot do this. The event website SEO guide covers the rest of what crawlers and AI assistants need to read the page.

Not if they share inventory — and they should, or you will oversell. Different prices per language is a different offer, which is a different event. Presenting another currency is a payments question, not a language-version question.