Match localized push keys to the app versions that contain them

Identify the assembly contract

Firebase documents platform-specific localization keys that reference strings in the installed app, with ordered string arguments substituted into those resources. The server therefore selects a resource contract, not merely a translated sentence. Check the current platform fields with engineering rather than copying Android field names into an Apple payload.

Create a plain-language record for each campaign message: resource identifier, intended meaning, argument count, argument meaning and first app release that contains it. A key called delivery_update is not enough if one release expects a date and another expects a shop name. Treat changed argument meaning as a compatibility change even when the key still exists. The evidence should come from the release artifact or resource inventory, not a designer's latest translation spreadsheet.

Separate supported versions from preferred versions

List the app versions that remain eligible for the campaign. An update available in the store does not establish that everyone installed it. For each supported version, record whether the requested key exists in the relevant locale and whether its placeholders still have the intended meaning. Include a device language that differs from the account's saved language, because those choices can lead to different text assembly paths.

Decide how to handle incompatible installations before scheduling. Options might include using an older compatible resource, sending separately reviewed server-rendered text through a supported path, or excluding that optional message. These are editorial and implementation choices, not a promise that the operating system supplies a suitable fallback. Do not invent missing-key behavior: have the app owner reproduce it on each supported path and record the result.

Test arguments as content, not just syntax

Use invented values that expose argument mistakes. A shop named North Pier and a date of 18 November are easier to distinguish than two short numbers. Test missing arguments, surplus arguments, unusually long values and a changed argument order. Ask a language reviewer to inspect the assembled notification rather than signing off only the underlying resource sentence.

Keep commercial facts consistent across variants. An older resource may say collection ready while the new campaign means collection available to reserve; using that key because it renders cleanly would create a different promise. Do not silently abbreviate eligibility or expiry to make a translation fit. If the installed resource cannot express the approved meaning, select another approved representation or do not send to that version. A successful rendering is necessary, but not sufficient.

Release the compatibility map with the campaign

Store the approved payload family beside its supported release range and rendered examples. Have one owner check the final targeting rule against that map immediately before sending. An audience export created before a version rollout may no longer represent the same installation mix; equally, an apparently old record should not be treated as proof of a current resource set.

After an app update, rerun the cases whose resources changed. Keep the exercise limited to synthetic installations and invented arguments, with no personal account details in screenshots. The acceptance decision is precise: these payloads express this promise on these app versions and locales. It does not claim that all future resources, operating systems or users will behave identically.

Make the reasoning concrete.

A fictional museum app adds a resource for reserving a workshop. Its newest release contains two arguments, workshop name and booking date; the previous release has only an arrival reminder with a similar label.

The museum rejects the misleading resource reuse and signs off rendered examples for each supported path. It does not infer compatibility merely from a matching key name.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Resource

   Which released artifact proves that this key exists?

2. Arguments

   What does each ordered argument mean?

3. Coverage

   Which versions and locales can express the approved promise?

4. Alternative

   What approved representation is used when compatibility is absent?

5. Evidence

   Which rendered fixtures expose missing or reordered arguments?

Watch for the wrong conclusion.

• Assuming store availability means universal installation.
• Reusing an old key whose commercial meaning differs.
• Approving translations without rendering their arguments.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not supplier implementation instructions or measured business results. Sources support only the specifically attributed platform facts. Supplier controls, contracts and local requirements can change; verify the actual placement and current provider guidance before implementation.

• Firebase: Localize notification messages →Primary platform documentation · Supports: Supports installed string-resource lookup and platform-specific ordered localization arguments; release gating and acceptance workflow are editorial.