A company decides its app needs to work in French as well as English. The task lands in the backlog as a single item, usually near the bottom, described as "add FR". Somebody gets a quote from a translation agency, the cost looks modest, and everyone moves on.
Six weeks before launch the reality arrives. Buttons overflow. The onboarding email is in the wrong language. A push notification goes out in English to everyone. The support agent cannot reproduce a bug because the screen name they were told about does not exist in their version. Legal asks which language the terms were accepted in.
The translation was never the hard part.
Two languages is an architecture, not a feature
The decisions that make bilingual work manageable are made early and are structural.
Every user-visible string has to live outside the code, which sounds obvious until an audit finds forty of them hard-coded in view files. Layouts have to tolerate text that runs roughly twenty to thirty percent longer in French than in English, which is why a button sized to its English label is a bug waiting to happen. Dates, numbers and currency formatting have to follow locale rather than being assembled by hand.
Then there is the content that lives outside the app binary: server-side error messages, emails, receipts, notifications, help articles, store listings. Each one needs a language to be chosen at send time, which means the user's language preference has to be stored, known to the backend, and respected everywhere. Teams that skip that step end up with a perfectly bilingual interface that emails everyone in English.
Language belongs to the user, not to the device
The common shortcut is to follow the phone's system language and stop there. It is a reasonable default and a poor rule.
People switch. A person whose phone is in English may want the app in French, or the reverse, and in a bilingual city that is common rather than exceptional. The preference should be explicit, changeable inside the app, stored with the account rather than the device, and applied on every channel.
That last clause is where most implementations leak. A preference held only on the phone cannot reach the mail server, so the moment a message is generated outside the app, the language is a guess.
Quebec has a legal dimension, and it shapes the plan
For anyone serving customers in Quebec, this is not purely a product choice. The Charter of the French language sets expectations for commercial software and digital services offered in the province, including that the French version be available on terms at least as favourable as any other language.
The practical translation of that principle is straightforward and worth writing into the requirements: French cannot be the version that lags. Not a smaller feature set, not a delayed release, not a screen that reverts to English because the string was added late, not a support experience that is faster in English.
Teams that treat French as a follow-up release usually discover that the follow-up is the compliance problem, which is why it belongs in the same sprint rather than the next quarter.
Testing doubles, and so does support
Every flow now exists twice. Every screenshot in the documentation exists twice. Every regression pass covers both, because layout breaks and missing strings appear in one language and not the other.
Support needs the same treatment. An agent has to be able to see what the user is seeing, which means the ticketing system should capture the interface language and the internal names of screens should be language-neutral. Otherwise half of every conversation is spent establishing which button is being described.
Content operations deserve a process too. Whenever a feature adds copy, both versions ship together. A workflow that lets English merge while French waits for a translator is the mechanism by which the second language gradually falls behind.
The quality question nobody wants to raise
Machine translation has become good enough that many teams use it as a first pass, and that is reasonable for volume. It is not sufficient for the sentences that matter.
Interface copy is dense, contextual and often ambiguous. A word alone in a button has no sentence around it to disambiguate. Product terms, legal language and error messages all carry precision that a literal rendering loses. The result reads as translated, which quietly signals to a French-speaking user that they are using the secondary version of the product.
The fix is not expensive: a bilingual reviewer with product context checking the strings that users actually see most. It is the difference between an app that is available in French and an app that was written in French.
Where the habit already exists
Montreal companies have been doing this for so long that the practices are ordinary rather than exceptional. Design reviews look at both languages, copy is written twice rather than translated once, and the legal requirements are known before scoping instead of discovered during it.
That is a real advantage when the deadline is close. Teams that build a mobile app in Montreal tend to plan the second language into the first release, because everyone involved has already seen what happens when it is added afterwards.
Do it once, at the start
Externalise strings from day one. Give language its own user setting and store it server side. Let layouts breathe. Ship both languages in the same release. Have a human review the copy that appears most.
None of it is difficult in isolation. All of it is expensive to retrofit, and the retrofit is exactly what most projects end up paying for.
