Bilingual Push Notifications That Stay Clear Under Tight Limits
Push notifications demand clarity in every language, but French text often runs 20–30% longer than English—a challenge that can break your message before it reaches the screen. This guide draws on advice from localization specialists and mobile UX designers to show how teams can craft bilingual alerts that fit character limits without sacrificing meaning. Readers will learn four practical techniques for writing notifications that remain concise, actionable, and effective across both languages.
Let French Set the Length Ceiling
French runs 15 to 25 percent longer than English for the same idea, and push notifications don't forgive that. I write the French version first when a campaign has to work in both languages, not the English one. English compresses easily. French does not, so translating English into French after the fact usually means truncation on the lock screen.
We ran into this with an e-commerce client in Belgium sending bilingual cart-abandonment pushes. The English version read fine at 45 characters. The literal French translation hit 60 and got cut mid-word on older Android devices, which is worse than short and complete.
The fix that stuck: write the shortest possible French first (nouns and imperatives, no filler like "n'oubliez pas de"), test it on an actual lock screen, then build the English from that length ceiling instead of the other way around. Parity isn't identical word count, it's identical meaning landing before the cut. We also stopped centering wordplay in either language for push, because the first casualty of a tight character count is the joke, and a truncated joke reads like a bug.
One habit that helped more than any style guide: read every push out loud in both languages before sending. If one sounds clipped and the other sounds natural, the shorter one becomes the master version, and the other gets rebuilt to match its length, not its wording.
Use a Compact Confirmation Line
The biggest mistake people make with bilingual notifications is treating them as a translation problem. It's a design problem. You're not writing copy twice. You're designing a single visual unit that has to land in under two seconds on a 4-inch screen.
Here's the principle I follow: lead with the dominant language of your highest-intent segment, and use the second language as a confirming signal, not a full repeat. Parity doesn't mean identical word count. It means identical emotional clarity.
One layout choice that consistently worked for us: putting the English line first, then a slash or pipe separator, then a compressed version in the second language. Not a full translation. A compressed restatement. So instead of "Your video is ready to share! / Nin De Shi Pin Yi Zhun Bei Hao Fen Xiang!" we'd do "Your video is ready / Shi Pin Yi Wan Cheng." The second version drops the exclamation energy and the extra verb phrase because the character budget demands it, and because the user already got the emotional hit from whichever language they read first.
The trick is understanding that most bilingual users aren't reading both lines with equal attention. They're scanning for the one that registers fastest, and the other line just confirms they're in the right place. So you optimize the primary line for emotional punch and the secondary line for informational completeness in fewer characters.
We tested this with our early user base when we were sending notifications about render completions. The version with two full-length translations got truncated on Android devices about 40% of the time. The compressed format, never. And click-through was actually higher because the notification felt cleaner, more intentional.
Stop thinking about bilingual notifications as "fairness between languages." Think about them as a single piece of UI where every character is real estate you're renting by the millisecond.
Put the Action at the Start
My version of this is character-limited campaign and lifecycle copy rather than app push specifically, but the constraint is identical: two languages, one budget, and a device that will cut whichever one runs long.
The rule that solves most of it is to write the language that expands first and let it set the budget, then work back into the shorter one. Everybody does it the other way round, because the brief is written in English, and the result is a line that sits perfectly in one language and dies mid-word in the other. If the longer language cannot carry the message in the space, the message is too long in both and needs rewriting rather than trimming.
Front-load the verb. Truncation eats the end, so the instruction has to survive the cut. A line that reads as an action in the first few words still works when the tail disappears, and one that builds to its point does not.
Never let a number split from its unit or its currency. A price cut in half is worse than no price at all, because it reads as an offer that is not there.
Google's ad headlines give you 30 characters, and that discipline transfers directly. Write to the tightest limit you have, test on the narrowest device you support rather than the one on your desk, and check the second language on a real phone.
Preview Both Versions on Real Phones
We build in a lot of languages, so this one comes up constantly. The mistake people make is they write the English notification first, get it perfect right at the character limit, then translate, and the other language blows right past the limit because it's simply longer. Spanish and German in particular run longer than English. So we flip it. We write for the language that expands the most first, get that one to fit, and then the shorter languages have room to breathe. That one change kills most of the truncation on its own.
On parity, we don't translate word for word; we translate the intent. A push has one job: get the tap, so both versions need to make the same promise even if the wording isn't identical. The phrasing rule that's saved us the most is front-load the important word. Phones cut the end of the string, not the start, so if the key info is in the first two or three words, you're still safe when it clips. We also keep the variable stuff, names and numbers, out of the middle of the sentence, because word order shifts between languages and a name jammed mid-sentence can read broken in one of them. Last thing, we always preview both on a real phone, not in the spreadsheet, because the spreadsheet lies about where the text actually wraps.
