A multilingual event screen needs a visible language choice before the first task, a way to change language during the task, and a complete path to the result in every language offered. Translating the opening screen while leaving instructions, errors, results, or staff prompts in only one language creates a broken experience. In a shared venue, each visitor's choice also needs a sensible reset for the next person.
Put language choice where the visitor needs it
Show language names in the languages themselves, for example “العربية” and “English,” rather than making people decode a flag. The W3C's internationalization guidance warns that flags identify countries poorly as language selectors and recommends clear access to alternate-language content. That guidance concerns websites, but the recognition problem also appears on a public screen that a stranger has only seconds to understand.
Do not guess language from location or a previous visitor's session. If staff greets someone in one language, the interface should still let that person choose another. Keep the selector available after the first screen; a visitor may discover the task is more technical than expected and want to switch. Preserve their selected item or current step where feasible. If language switching restarts the experience, say so before it happens.
A 2025 multiple-case study of Turkish-speaking families in Dutch science museums observed families choosing among available languages in museum activities, including digital kiosks, and moving between languages to make sense of content. That setting cannot tell an event team which language visitors will prefer, but it cautions against assuming a single choice will always match an entire group's needs. Multilingual science museum family study, 2025.
Design the entire task in both directions
For an Arabic–English interface, test layout direction and mixed-script content, not only the translation file. W3C explains that HTML's dir attribute establishes right-to-left base direction, while language declarations identify the language; they solve different problems. The guidance also recommends logical layout properties such as start and end to support direction changes. W3C, structural markup and right-to-left text.
Check the product name, numerals, dates, email address, QR destination, and any Latin acronym inside Arabic text. Read the result on the installed screen from the normal viewing distance. A layout that looks balanced in a design file may clip a longer translation or reverse the meaning of a progress arrow. If the interface is browser-based, WCAG 2.2's language-of-parts explanation explains why changes of language should be programmatically identified for assistive technology.
Brief translation as a content system
Give translators the visitor's task and the meaning of each label, rather than isolated strings. Keep one approved source of truth for product claims, legal text, and event dates. Review error messages and empty states as carefully as the hero copy. Staff should have matching short explanations in the supported languages, or a clear route to someone who can help. A language button cannot compensate for an untranslated result or a staff-only finishing step.
Test with first-time speakers of each language. Ask them to complete the same task, correct a mistake, switch language midstream, and identify the next step. Record where they stop or ask staff for help. This is distinct from a bilingual website URL structure: the event problem includes shared-device reset, a physical audience, short sessions, and language choice while someone else may be watching.
Archv designs interactive experiences and multilingual brand systems. For a new event project, the acceptance test should include the complete path in each supported language on the actual hardware, not just approved translations on a spreadsheet.