How to build a multilingual conference website

Not everything belongs in every language

Abstract titles may stay in the language of the science. Practical pages — venue, visas, registration categories — often need the host language. Decide that split in public, or volunteers will translate the programme twice and still miss a room change.

Live data is the usual failure

Static paragraphs are easy to translate once. Rates, deadlines and session times change. If each language is a separate CMS tree, one of them will be wrong. A conference website that publishes from operational records can switch language without cloning the timetable.

Language is not a theme colour

Switchers should name the language of the page you land on. Dates, currency and address formats follow locale. Accessibility means the HTML language attribute matches what the reader sees — including on Eventumbot’s own marketing site, which ships English, French, German and Spanish.

Who writes the second language

Software does not replace a translator for scientific claims or legal text. Organisers remain responsible for meaning. What the platform can do is stop a communications intern from retyping session titles into a second brochure the night before opening.

Localisation checklist

Work through this list for each language you publish.

• Decide which languages are complete and which pages exist in each.
• Translate the visible text, page titles, descriptions and image alternative text.
• Keep programme data, dates and fees in one source and show the same values in every language.
• Localise dates, times, currencies and number formats.
• Translate the registration form, confirmation email and invoice text.
• Provide a language selector on every page with labels in each language’s own name.
• Link between language versions of the same page, not to the home page.
• Have a native speaker in the field review technical terms.

Content inventory example

List every page with its owner, its languages and its source of truth. A short table prevents the common failure, where the English page is updated and the others are not.

Page: Registration Owner: Treasurer Languages: EN, FR, DE, ES Source: fee table in the registration record Page: Programme Owner: Programme chair Languages: EN, FR, DE, ES Source: programme records; session titles stay in the language of the abstract

The multilingual user journey

A visitor who chooses French should be able to read the call, submit, register, pay and receive emails in French. Test that path from start to finish, and check that the language choice is remembered and that no step falls back silently to English.

Choosing which languages to offer

More languages are not always better. Each one is a promise that everything important exists in it and is kept up to date. Start from your audience: the languages of the countries that provide most of your participants, of the society’s membership and of any funders. Then check what you can maintain. A site that offers three languages well serves people better than one that offers six with gaps. Decide which pages exist in every language, and mark clearly any that are English only.

What to translate and what to leave

Not everything needs a translation, and some things should not be translated.

• Translate: the call, the programme structure, registration, fees, venue and travel, contact, the policies.
• Consider translating: keynote biographies, sponsor descriptions.
• Leave in the original: abstract titles and texts, which are the authors’ own; show the language of each.
• Do not translate: names of people and institutions, and the meeting’s official title, though you can add a translation beside it.
• Keep numbers, dates and units in a form each reader will understand.

URLs and the language switcher

Give each language its own address, such as a folder for each language, so that every version can be linked, bookmarked and found. Put a language selector on every page, using each language’s own name, for example “Deutsch” and not “German”. When a reader switches, take them to the same page in the other language, not to the home page. If a page does not exist in that language, say so and offer the nearest equivalent. Link the language versions of a page to each other in the page’s technical markup so that search engines can show the right one to the right reader.

Programme data and abstracts in several languages

Session titles, room names and times should come from one record, with translations of the labels attached. Times and rooms never differ between languages. Abstracts are usually published in the language they were submitted in, so mark the language on each and allow filtering. Keep a translated field only where you have the resources to maintain it: an abstract translated once and then edited in the original will be out of date within a week.

Working with translators, and a glossary

Machine translation is a fair first draft but should be checked by a person who knows the field. Give translators the context, the audience and a glossary of terms so that “track”, “abstract”, “chair” and “early-bird” are always translated the same way. Ask them to point out sentences that only make sense in English. Keep a glossary as a simple table and share it with anyone who writes for the site.

English French German Spanish abstract résumé Abstract resumen track thème Track línea temática chair président de séance Sitzungsleitung moderador early-bird early bird Frühbucher tarifa anticipada programme programme Programm programa

Keeping language versions in step

The hardest part of a multilingual site is not the launch, but the third week, when something changes. Name one owner for each language, and make one person responsible for triggering updates when the source changes. Record the date each language version was last checked, and show it to editors. When a change is urgent, such as a deadline, publish it in every language on the same day, even if the wording is short, and improve it afterwards.

Emails, forms and receipts in the reader’s language

A visitor who chose German and receives an English confirmation email has been let down at the most important moment. Store the language preference at registration and use it for confirmations, reminders, invoices and receipts. Translate the error messages of forms, since “Ungültige Eingabe” helps more than “Invalid input” for a German reader. Test each email and form in every language before launch, on a phone as well as a computer.