Push notifications are brief by design, but localising them well involves more than translating a title and body. A useful notification must use the recipient’s language, reflect local conventions, arrive at an appropriate time and preserve the meaning of the action being requested.

For product and engineering teams, the main challenge is separating message intent from the words eventually shown on a device. This makes it possible to reuse notification logic across markets while giving translators and local reviewers enough context to produce natural copy.

Start with a localisation model

Before adding translations, decide which data determines a notification’s language and regional behaviour. A common model uses an account or profile locale, with a device-level locale as a fallback. The exact choice depends on the product.

An account locale is usually more consistent for services where users sign in across several devices. A device locale may be more appropriate when the notification should follow the language configured on a particular phone or browser. Whichever model you choose, document the precedence rules and apply them consistently.

Keep these concepts separate:

  • Language, such as English, French or Japanese
  • Region, such as en-GB, en-US or pt-BR
  • Time zone, which determines when delivery is appropriate
  • Formatting preferences, including dates, times, numbers and currency
  • Notification permission and delivery status

Do not infer a user’s preferred language solely from an IP address. It can be wrong for travellers, VPN users, shared networks and people who deliberately use a different language from their location.

Store a canonical locale value where possible, and define a supported-locale fallback. If a requested locale is unavailable, fall back from a regional variant to its base language, then to the product default. For example, a missing en-AU translation might fall back to en before using the default language. Make this behaviour observable so missing translations do not fail silently.

Localise intent, not just strings

A translation file cannot provide enough context for every notification. Translators need to know what happened, who performed the action, what the recipient should do and where the text will appear.

Give each message a stable key based on its meaning rather than its English wording. A key such as payment_failed is more durable than payment_could_not_be_processed. Include context alongside the key:

  • The event that triggered the notification
  • The audience and user role
  • The variables available to the translation
  • Whether the message is urgent, informational or promotional
  • The destination after tapping
  • Character or layout constraints

Avoid assembling sentences from fragments. Joining a translated greeting, verb and noun can produce incorrect word order, agreement or case endings. Localise the complete message or use a translation system that supports variables, plural rules and grammatical context.

Variables should represent data, not pretranslated sentence fragments. A quantity should remain a number that the locale-aware renderer can format. A person’s name, product name or order reference should be clearly marked as a value and safely escaped where appropriate.

Design payloads for translated content

A push request should carry the content required for the chosen audience and locale, rather than relying on the client to guess what the server meant. With HoneyNotify, server-side sends use POST /v1/notifications with a Bearer API key and an Idempotency-Key. Each notification requires a title, body and target.

For localised delivery, your application can resolve the locale before sending and create the title and body for that audience. Targets can address a device, user, tag, segment or all enabled devices. A user or segment target is generally easier to manage for language-based audiences than maintaining a separate list of device identifiers in application code.

The right approach depends on how much variation you need:

  • Send one localised notification per language or region to a matching user or segment
  • Resolve content per recipient when each user may have different variables or preferences
  • Send a neutral event and let a client render it only when the product genuinely requires device-local presentation

Server-side rendering gives you central control, consistent analytics and easier auditing. It also requires careful batching, retry handling and protection against exposing sensitive content in logs. Client-side rendering can react to the current device locale, but it adds platform-specific behaviour and may fail if the device does not have the required data or the application cannot process the payload in time.

Do not include every language version in a visible notification payload unless there is a specific reason. It increases payload size and can expose content that is not intended for the recipient. Keep routing and localisation decisions on the server when the message contains personal or transactional information.

Handle pluralisation and regional conventions

Plural rules differ between languages, and some languages have more than two plural forms. Treating every language as singular or plural can create incorrect copy. Use an internationalisation library or translation system with locale-aware plural categories rather than writing conditional logic for only English.

Dates, times and numbers also need deliberate treatment. A notification about an appointment should use the recipient’s time zone or clearly state the relevant zone. A date such as 03/04 can be ambiguous between markets. Currency symbols and decimal separators need the same care.

Be cautious with idioms, humour, urgency and cultural references. A phrase that sounds friendly in one market may sound vague or overly familiar in another. Review calls to action as well as descriptive text; the label should match the screen the user will see after tapping.

Short notifications are not automatically easy to translate. German can require more space than English, while some scripts behave differently in line breaking and character width. Write concise source copy, but do not impose an arbitrary character limit that makes a correct translation impossible. Test how each platform truncates, wraps or displays the notification.

Choose delivery times responsibly

Localisation includes timing. A notification that is useful during working hours in London may arrive overnight in Singapore if the system uses one global schedule.

Store a reliable time zone for each recipient or account, and define what happens when it is missing. For scheduled campaigns, calculate the intended local delivery time before creating the send. For event-driven alerts, consider quiet hours, urgency and the consequences of delay. A security warning and a marketing reminder should not necessarily follow the same rules.

Daylight-saving changes are another reason to use time-zone identifiers rather than fixed offsets. Recalculate future schedules when the relevant time-zone rules change, and make the chosen time visible in internal tools so support teams can explain delivery behaviour.

Build a translation workflow that can be tested

Treat notification copy as product content, not an afterthought in application code. Keep translation keys under version control and require review when the meaning, variables or destination changes.

A practical workflow includes:

  • Create the source message with context and approved variables
  • Translate it into supported locales
  • Check placeholders, plural rules and forbidden or sensitive terms
  • Review the rendered title and body on each target platform
  • Test the fallback path with a missing or unsupported locale
  • Release copy independently where your tooling permits it
  • Monitor delivery, open behaviour and user feedback by locale

Test actual notification payloads, not only translation files. Include long names, large quantities, missing optional values and characters from the scripts you support. Check right-to-left languages if they are in scope, including punctuation, alignment and the direction of variable values.

HoneyNotify client SDKs cover device registration, identity, token lifecycle, payload handling and lifecycle events across iOS, Android and Web Push. Use those lifecycle capabilities as part of your test plan: a successfully localised server request is not enough if the device registration or token state is stale.

If you migrate from another provider, validate identity and token mapping before assuming existing device records will receive new sends. Imported OneSignal subscription IDs can remain as device IDs when matching provider tokens later register, but token rotation or another provider environment can prevent matching. Test migration with real registration flows and treat unmatched records as a delivery and data-quality issue.

Common mistakes

### Translating after delivery logic is complete
If routing, timing and copy are built independently, the system may send the right words to the wrong audience or at the wrong local time. Resolve locale, audience and schedule as part of one notification decision.

### Using one fallback for every problem
A missing translation, unknown locale, missing time zone and invalid variable are different failures. Record them separately and define a safe behaviour for each.

### Assuming locale means language only
Regional conventions affect spelling, dates, numbers, legal wording and expectations around timing. Decide which differences matter for each notification type.

### Ignoring idempotency during retries
A timeout can leave the sender unsure whether a notification was accepted. Use an Idempotency-Key for server-side sends and make retry behaviour deliberate, so a translation or network failure does not produce accidental duplicate notifications.

### Treating a translation as permanent
Product terminology changes. Keep keys stable where possible, but review translations when workflows, screens or calls to action change. A linguistically correct message can still be misleading if the destination no longer matches it.

Conclusion

Effective push localisation combines audience modelling, translation quality, regional formatting, time-zone-aware delivery and platform testing. Keep message intent separate from rendered copy, use explicit locale and fallback rules, and validate the complete path from identity and token registration to the notification shown on a device. This creates a system that can expand into new markets without duplicating notification logic or compromising the user experience.