Skip to content
EMPOBase
en

Working in several languages: what to ask software vendors

By the EMPOBase team · · 4 min read

Short answer

Ask which interface languages the vendor supports and how complete each one is, then test your own language on real screens. Check whether your content, names, exports and notifications work in your scripts, including right-to-left text. Ask who translates new features and what happens to untranslated text. Expect gaps and plan for them.

Key points

  • Support for a language can mean a full interface or only part of it; ask for coverage by screen.
  • Test your real names, scripts and dates, not a demo.
  • Check exports, emails and reports, not just the main screens.
  • Plan staff training and help material in the languages your people use.

Why does language support matter for NGOs?

NGO teams often work in more than one language. A head office may report in English while field staff use Arabic, Burmese, Spanish, French or a local language. If the software works only in one of them, some people will not use it, or will use it badly, and the records will have gaps.

A software language list on a website is only a start. You need to know how complete each language is and where the gaps are.

There is also a fairness side. If only head office staff get a screen in their language, power over the records moves to them. Field staff then depend on others to enter and check their data. Good language support lets the people closest to the work own their records.

What does “supported” really mean?

Vendors use the word in different ways. Ask which of these they mean.

LevelWhat it means
InterfaceMenus, buttons and messages appear in the language
ContentStaff can type and store text in the language
OutputReports, emails, exports and PDFs handle the language
HelpGuides, training and support are available in the language

A language may reach the first level and miss the rest. Ask for coverage by screen, not just a yes or no, and ask what the user sees when a phrase has no translation.

What should you test with your own data?

Do a short test with real material from your team.

  1. Names. Enter real staff and partner names, including long names, names with accents and names in non-Latin scripts.
  2. Text direction. If you use Arabic or another right-to-left language, check that screens, tables and reports read correctly.
  3. Dates and numbers. Check date order, number format and calendars your team uses.
  4. Search. Search for a word in your script. Does it find the record?
  5. Export. Export a report to a spreadsheet and a PDF, and open both. Look for broken characters.
  6. Email and notifications. Check which language they arrive in, and whether the user can choose.

Ask a native speaker to do this, since only they can judge whether the wording reads naturally. Write down each problem with a screenshot and send the list to the vendor. How fast and how clearly the vendor replies tells you a lot about how it will treat language problems after you sign.

Test in the same way on a phone, because many field staff use a small screen. Long words in some languages wrap badly or hide buttons, and you only see this on the real device.

Who keeps translations up to date?

Software changes often. A language that is complete today may fall behind next quarter. Ask:

  • Who translates new features, and how fast?
  • Is a person or a machine doing it, and who reviews it?
  • Can users report a poor translation?
  • Do all plans include all languages?

If a vendor cannot answer, assume that gaps will grow over time. Ask also whether the vendor has staff or partners who speak your language, because support questions are much easier in the same language. Ask what happens if you find an error in a translation: is there a form, a contact, a promise of a fix?

How should you plan for gaps?

Every multilingual team has to deal with gaps.

  • Agree a working language for shared records, so a country office and head office read the same terms.
  • Keep a short glossary of key terms and their translations, such as indicator, grant and beneficiary.
  • Train in the language people speak, and write short help notes in it.
  • Decide which records need a translation for donors, and who is responsible.
  • Budget time for it. A bilingual report costs more staff hours than a single-language one, and the cost is easy to forget.
  • Review the glossary once a year with the people who use the terms daily.

Our article on choosing operations software shows how to place language among the other criteria.

Where EMPOBase fits

EMPOBase has nine interface languages. Coverage varies by screen, and some content appears in English, so test the screens your team will use before you commit. Some languages are further along than others. Content your staff type stays in the language they typed. An AI assistant can offer English and Burmese translation help; review any AI output before you rely on it. The documentation and the platform page show what exists today, and you can ask us for a test account.

Questions people ask

Does a translated interface translate our data too?

Usually not. The interface labels change, but records that your staff type stay in the language they were written in. Ask whether the software offers any translation help and how reliable it is.

What if the vendor does not support our language?

Ask whether staff can still enter data in your language and whether names and text display correctly. A missing interface language is less serious than a system that breaks your script.

Who should test the language?

The people who will use it daily. A manager who does not read the language cannot judge the quality of the screens.