Short answer: as far as we know, neither Altru nor Raiser’s Edge NXT has a “translate this email” button. Neither one will take an English acknowledgment letter and send a Spanish copy to the people who prefer Spanish. If your version has changed, ask Blackbaud support or check the current release notes before you build anything. Either way, multilingual communication from these systems is mostly a data and template job, not a translation feature.
The good news is that the setup is the same in both products, and you can get most of it working with tools you already have.
Step one: record the language people want
You can’t send someone a Spanish renewal notice if the database doesn’t know they want one. Before you think about translation, make sure every constituent record can hold a preferred language.
- In Altru, the usual approach is a constituent attribute (for example, “Preferred language”) backed by a code table, so values stay consistent: English, Spanish, Vietnamese, and so on. Avoid a free-text field. “Spanish,” “Español,” and “SP” will break your queries later.
- In RE NXT, a constituent custom field or attribute with a fixed list of values does the same job. Some organizations also use the language field on the constituent record if theirs is set up and in use. Check with whoever manages your configuration before adding a duplicate.
Then decide how the value gets filled in. Good sources include a language question on your membership and donation forms, front desk staff asking at the register, school group and tour bookings, and volunteer intake. Leave the value blank when you don’t know. Never fill it in based on a name or address. That guess is unreliable and can come across as presumptuous.
Step two: segment with queries, not by hand
Once the language field exists, add it as a filter or output column in the queries behind your communications. Every recurring send (renewal reminders, acknowledgments, eTickets, event invitations) then splits into one list per language you support, plus a default list for everyone else. Blank records go to the default, which is usually English or a bilingual version.
Keep the number of supported languages honest. Supporting two languages well is better than supporting six where half the templates are out of date.
Step three: build one template per language
This is where the translation actually happens. Here are the realistic options, roughly from most to least reliable:
- Professional or community translation of each template. Your communications are mostly reusable templates, so the cost is a one-time project rather than an ongoing one. A bilingual staff member or volunteer reviewing the result is worth a lot.
- Machine translation, then human review. General translation tools are good enough for a first draft of a renewal email. They are not good enough to send unreviewed, especially for donation language, tax receipt wording, and anything with a deadline or a dollar amount.
- Bilingual single templates. One email with both languages, with the shorter or preferred one first. This is clumsy for long letters but practical for eTickets and short confirmations, and it removes the need for a language field on every record.
Merge fields work the same in every language version. Just check that the surrounding sentence still reads correctly around a name, date, or amount. Date and currency formats are worth a second look, since some audiences read 04/05 as May 4.
What to have a human check every time
- Gift acknowledgments and tax receipt language. If the receipt wording carries legal meaning where you operate, confirm the translated version with whoever approved the English one.
- Membership benefits, prices, and expiration rules. A mistranslated benefit becomes a promise someone will hold you to.
- Your organization’s name, exhibit names, and program names. Decide whether these get translated at all, and be consistent.
- Special characters and accents. Send a test to yourself from the actual system, not just from a preview, and confirm that letters like ñ, é, and ü come through intact.
Step four: decide where the send happens
If you send email directly from Altru or RE NXT, you’ll maintain a separate template or appeal effort per language and point each one at its segmented query. If you export lists to an email marketing platform, the language field becomes a tag or audience field there, and you build language variants in that tool. Some email platforms have their own translation or multi-language features. Check what yours supports, and the same human-review rule still applies.
Whichever route you take, keep the language value in Altru or RE NXT as the single source. If someone updates their preference in your email tool, make sure that change gets back to the constituent record. Otherwise the next printed mailing goes out in the wrong language.
Don’t forget the rest of the trip
A translated email that links to an English-only renewal page or donation form only gets the guest halfway. Before you launch, click through every link in each language version and note where the experience switches to English. Sometimes that’s fine, since a short note like “this page is in English” sets expectations. Sometimes it means the form or landing page needs its own translated version first.
Quick answers
Can we just turn on automatic translation for every outgoing email?
Not natively in either product, as far as we know. Even if your email platform offers it, sending unreviewed machine translation on receipts and membership terms is risky. Translate the templates once, review them, and reuse them.
Which communications should we translate first?
Start with the ones people act on: eTickets and visit confirmations, membership renewals, and gift acknowledgments. Newsletters can follow.
How do we handle households with mixed preferences?
Store the preference on the individual, and for household mailings either use the primary contact’s language or send a bilingual version. Pick one rule and document it.
