Your App in Your Customers' Language: Launching English, French and Spanish

Most diaspora senders can get by in the language of the country they live in. That is not the same as being comfortable sending a month's savings home in it. When the app speaks the sender's first language, the moments that cause hesitation, such as entering a recipient's bank details, reading a scam warning or understanding why a transfer is on hold, become much easier to get right.

For an operator, language is not cosmetic. It affects whether a new customer finishes a first transfer, how often they contact support and how many payouts are rejected for wrong recipient details.

This guide is for growth and product leads planning to offer their app in more than one language: what to localise, how to own the wording, how to roll out on one corridor, what to test and how to measure the result.

We use RemitSo as one example of how this can be done. RemitSo's customer app can run in English, French or Spanish, switched on with a translation dictionary that the operator provides. The platform handles the switching: every screen, message and alert changes language, and emails go out in the customer's own language. What the platform does not do is write your translations for you. Your team, or a translator you appoint, still decides the wording, checks it against your legal texts and signs it off. That split is deliberate, and the rest of this guide explains why it works in your favour.

In a money transfer app, misunderstanding a screen costs the customer money and the operator time. Three effects matter.

Trust at the point of payment

Senders are handing over money and personal documents to a brand they may have found only recently. Clear, natural wording in their own language signals that the business understands who it is serving. Wording that reads like a machine translation does the opposite, especially on the screens where the customer confirms the amount, the fee and what the recipient will receive.

Fewer avoidable support contacts

Many support contacts are not problems at all, just customers who did not understand a status, a document request or why a transfer is waiting. Explained in their first language, some of those contacts never happen, and the rest are easier to resolve.

Fewer mistakes in recipient details

Recipient forms vary by payout method: account numbers, branch codes, mobile wallet numbers, names exactly as on an ID for cash pickup. Labels the customer fully understands reduce wrong fields, swapped names and mistyped numbers, each of which becomes a rejected payout, a refund or a manual correction.

Ask your support team which questions they answer most often in your target corridor, and in which language. That list is usually the business case.

A common mistake is to translate the main screens and leave everything else in English, so customers switch language at the most sensitive moments. Scope the work by following a transfer from sign-up to delivery and listing every piece of text the customer sees.

• Screens: sign-up, sign-in, ID check and selfie, the send flow, recipient forms for each payout method, the review screen with the rate, fee and "Total to pay", settings and help.
• In-app messages and errors: validation messages on forms, payment failures, requests for documents, hold explanations.
• Push notifications: every status change in the transfer, worded for bank deposit, cash pickup or mobile wallet.
• Emails: welcome, verification, transfer confirmations and status updates, receipts.
• Scam warnings: who the customer should pay, who they should never pay, and what your brand will never ask for.
• Receipts and statements: the documents customers download and sometimes show to others, such as family members or a bank.
• Legal and policy texts: terms, privacy notice, complaints procedure, and any regulator-required disclosures.

Localising also means adapting. Number and date formats, name order, formality and the words customers use for "cash pickup" or "mobile money" differ between markets that share a language. French for senders in Canada, France and West Africa is not identical, nor is Spanish in Spain and the United States. Decide which audience the dictionary is written for.

There are broadly three ways an operator ends up with a multilingual app. The table below compares them from a product lead's point of view.

A translation dictionary is a list of every piece of text in the app, each with a key and its wording in each language. The platform reads the dictionary and shows the right wording for the customer's chosen language. Because the operator supplies the dictionary, the operator decides how the brand sounds: whether it addresses customers formally or informally, which word it uses for "recipient", and how it phrases a hold or a refusal.

To make this work in practice:

1. Appoint an owner. One person, usually in product or marketing, owns the dictionary for each language and approves changes.
2. Write a short glossary first. Fix the translation of twenty to forty core terms (transfer, recipient, payout, cash pickup, rate, fee, total to pay, verify, hold) before translating anything else. This keeps the app consistent.
3. Give the translator context. A key with a screenshot is far easier to translate well than a bare sentence.
4. Route legal texts separately. Terms, disclosures and complaint wording should be reviewed by whoever signs off your legal texts in the source language.
5. Keep it under version control. When the app gains a new screen, new keys appear. Have a routine for spotting untranslated keys before each release.

Legal texts need one more rule: once a customer has accepted a version, that version must stay exactly as it was, in the language they read it in. If you change the French terms, publish a new French version rather than editing the old one. RemitSo applies this to wallet terms, where the licence allows wallets (an optional add-on): terms are versioned per country and language, and a published version is never edited, so you can always show which wording a French-speaking customer agreed to and when.

The following plan is illustrative. The numbers are examples chosen to make the steps concrete, not benchmarks.

An operator based in Canada already serves several corridors in English. It wants to grow its Canada to Côte d'Ivoire corridor, where many senders live in Quebec and are more comfortable in French. Support data shows that this corridor generates noticeably more contacts per transfer than the operator's other corridors, and that a large share of them are questions about document requests and recipient details for mobile wallet payouts.

Weeks 1 to 2: scope and glossary

• The product lead exports the full dictionary of app, notification and email text.
• Support lists the twenty questions most often asked on this corridor. These become priority areas for clear wording.
• The team agrees a glossary of around 30 terms, including how to refer to mobile money and cash pickup in a way senders from Côte d'Ivoire recognise.
• Compliance confirms which legal and regulatory texts need a reviewed French version before launch.

Weeks 3 to 4: translation and review

• A translator with financial services experience works through the dictionary with screenshots.
• A native French-speaking member of staff reviews the send flow and recipient forms on a real phone; legal reviews the terms and complaints text.

Week 5: test on staging

• The team runs the QA checklist below on iOS, Android and web.
• Every transfer status is triggered at least once so that each push notification and email can be read in French.

Weeks 6 to 9: limited launch, then general availability

• French is offered first to new and existing customers on this corridor only, for example to the first 200 customers who choose it.
• Support tags every French-language contact for the first month so that confusing wording can be found and fixed in the dictionary.
• After four weeks with no unresolved wording issues, French is made available on all corridors.

The operator then compares the four weeks before and after launch on the corridor. Suppose, purely for illustration, that the corridor had 1,000 completed transfers and 120 support contacts in the month before (12 per 100 transfers), and 1,100 completed transfers and 99 contacts in the month after (9 per 100). The useful conclusion is not the exact figure but the direction, combined with a reading of what the remaining contacts are about.

Most localisation defects in payment apps fall into a small number of categories. Work through these on every platform you support.

Names and recipient details

• Accented characters (é, è, ç, ñ) display correctly and are accepted in name fields where your payout partners accept them.
• Help text explains how to enter a name exactly as it appears on the recipient's ID or bank account.
• Form labels match the payout method: an account number, a mobile wallet number and a cash pickup name are clearly different things in the translated text.
• Validation messages are translated too. In RemitSo, each payout channel defines the recipient details it requires, with validation, so every error a customer can trigger on a recipient form should be checked in the new language.

Amounts and rates

• Decimal and thousands separators are shown as customers in that market expect, and nobody can misread 1.000 as one rather than one thousand.
• Currency codes and symbols are unambiguous, particularly where two currencies share a symbol.
• The review screen shows the rate, the fee and "Total to pay" without truncation in the longer French or Spanish wording.

Dates and times

• Dates cannot be confused between day-month and month-day order. Where in doubt, write the month as a word.

Legal and compliance texts

• Terms, privacy notice and complaints procedure are the reviewed versions, not drafts.
• Scam warnings name your brand as the payee and state who the customer should never pay.
• Document requests and hold messages are clear about what the customer must do next.

Layout and completeness

• No button, label or notification is cut off. French and Spanish strings are often longer than English.
• No untranslated keys or English fallbacks appear anywhere in the flow.

Decide on your measures before launch, and compare customers who chose the new language with the same corridor before launch, not with your whole customer base.

• First-transfer completion: the share of new sign-ups who complete a first transfer, including the ID check that happens inside it.
• Support contacts per 100 transfers: split by topic, so you can see which questions disappeared and which remain.
• Recipient detail errors: payouts rejected or returned because of wrong or mismatched recipient details.
• Repeat sending: how many customers send again within 30 or 60 days.
• Language adoption: how many customers choose the new language when it is offered. Low adoption may mean the option is hard to find, not that it is unwanted.

Read these alongside support conversations: a few customers quoting the same confusing phrase is reason enough to change the dictionary.

RemitSo provides the multilingual mechanics; your team provides the words and the judgement. Here is how the relevant features map to the work described above.

• English, French or Spanish from your own dictionary: you supply the translation dictionary, so your brand voice, glossary and legal wording stay under your control. See the customer app features.
• Every screen, message and alert switches: customers do not drop back into English during the send flow, ID check or a document request.
• Emails in the customer's own language: confirmations and updates outside the app match the language the customer chose.
• Scam warnings that show your brand as the payee: customers see exactly who to pay and who never to pay, in the language they read best.
• Transfer updates worded for the delivery method: push notifications and the delivery timeline distinguish bank, cash pickup and mobile wallet, which cuts down on "where is my money" contacts.
• Recipient forms that match each payout method: each payout channel defines the recipient details required, with validation, so clearer, method-specific fields help reduce rejected payouts from wrong details.
• Versioned wallet terms per country and language, where your licence allows wallets: a published version is never edited, so the wording each customer accepted is preserved in their language.
• Receipts and statements downloadable any time: customers can retrieve their own records instead of contacting support.
• Releases tested on your staging first: you can run the full language QA before customers see a change. Track new features in the release notes.
• Messages from the admin panel: news and rate alerts reach customers who opted in, managed through broadcast management. See the admin features.

Your team still owns the translations, the glossary, legal review, QA sign-off and support in the new language. If you are planning a new corridor alongside the language, the getting started page sets out how a launch is organised, or you can book a demo to see the language switch on a working app.