A family visiting from across town lands on your ticket page, reads the event description in Spanish on your website, clicks “Buy tickets,” and suddenly everything is in English: the date picker, the quantity labels, the error messages, the terms they have to agree to. Some of them push through. Some of them close the tab.
Making Altru web forms work in more than one language is possible, but there’s no single switch for it that we can point to with confidence. What you can do depends on how much of the form you control, how many languages you need, and how much ongoing maintenance your team can take on. Below are the realistic options, from lightest to heaviest.
Start by confirming what Altru gives you natively
Altru web forms are designed in Altru and published to your site, and you can edit much of the visible text: headings, instructions, field labels, and confirmation messages. What’s less clear is whether every piece of text can be changed. System-generated wording such as validation errors, payment field labels, and some buttons may be fixed, and a form-level language setting may not exist for your form types.
Before you plan anything, test it. In a sandbox or an unpublished copy of a form, change every label you can find to another language, then run a full test transaction, including a deliberate mistake like a missing email address. Note every bit of English that survives. That list is your real gap, and it’s worth sending to Blackbaud support to ask whether any of those strings can be changed.
Option 1: Separate forms per language
The most dependable approach is to build a duplicate of each form and translate every editable label by hand. Your Spanish event page links to the Spanish form; your English page links to the English one.
Why it works:
- A person translates the text, so prices, ticket names, and policy language say exactly what you mean.
- You can tell from the form or source which language a buyer used, which helps when you report on outreach to multilingual audiences.
- Nothing depends on a visitor’s browser settings.
What it costs you:
- Every change happens twice. New ticket price, new membership level, new waiver text: each one has to be made on both forms, and drift is easy.
- Any system text that can’t be edited stays in English, so the experience will still be mixed.
- Confirmation and receipt emails need their own translated versions, or the buyer gets a Spanish form and an English receipt.
To keep this manageable, limit it to the forms that matter most (usually general admission, membership join/renew, and donations), and keep a simple checklist of “if you change form X, also change form X-ES.”
Option 2: Browser or widget translation
Visitors can already use the translate feature built into Chrome, Edge, or Safari, and some sites add a translation widget. It’s tempting because it costs nothing and covers every language at once.
Be careful with it on transaction pages:
- Accuracy. Machine translation can mangle ticket type names, membership level names, and refund or liability language. That matters when someone is paying.
- Embedded content. If your form is embedded in your website, a translation widget on the parent page may not reach inside it. Test before you promise anything.
- Form behavior. Translation tools rewrite page text on the fly. Occasionally that interferes with dropdowns or layout. Run a few test purchases with translation turned on before relying on it.
A reasonable middle ground: don’t build anything around machine translation, but don’t block it either. Visitors who already use it will keep doing so.
Option 3: Translate around the form, not inside it
If duplicating forms is too much work, put your translation effort into the page that surrounds the form. A translated landing page can explain ticket types, prices, what’s included, the refund policy, and a short “what each field means” guide, then link to the English form. It isn’t a full fix, but it removes most of the uncertainty that makes people abandon a purchase. Add a phone number or email staffed by someone who speaks the language, if you have one.
Don’t forget the data side
Whichever route you take, capture the language. If your form allows a custom question or attribute, ask for preferred language and store it on the constituent record. That lets you build queries to send future emails, renewal notices, and event invitations in the right language, which matters as much as the form itself. If you use separate forms, you can also infer language from which form the transaction came through.
Also check where English still shows up after the sale: eTickets, acknowledgment letters, membership cards, and printed materials at admissions. A bilingual form followed by an English-only ticket undoes some of the work.
Choosing an approach
- One additional language, a few key forms: separate translated forms plus translated confirmation emails.
- Many languages, limited staff: translated landing pages, plus a tolerance for browser translation.
- Language access is a core part of your mission: test thoroughly how much of the Altru form text you can actually control, and be ready to look at checkout options outside native web forms if the gaps are too large.
If you’re evaluating a different checkout
Our Checkouts product replaces Altru web forms with a branded, mobile-friendly checkout for tickets, memberships, and donations, with the data written back to Altru. If multilingual checkout is a requirement for you, bring your list of languages and the specific text you need translated to a demo and ask us directly how we would handle it, rather than assuming either way.
