"title" and "body" get priority over "titleLocKey" and "bodyLocKey"

[GP4cK]

Initially created the issue in the flutterfire repo.

[REQUIRED] Step 3: Describe the problem

Steps to reproduce:

When sending a notification with both title and titleLocKey, the app would prioritise title over titleLocKey when displaying the notification. I would expect that if a translation is found, then it should be used. Otherwise (maybe the user hasn't updated the app), then it should default to the title.

Relevant Code:

I think the relevant code is here. We should be swapping getString and getLocalizedString like so:

public String getPossiblyLocalizedString(Resources resources, String packageName, String key) {
    String localized = getLocalizedString(resources, packageName, key);
    if (!TextUtils.isEmpty(localized)) {
      return localized;
    }

    return getString(key);
}

Or is it the expected behaviour?

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[argzdev]

Hi @GP4cK, thanks for reporting. I'm able to reproduce the same behavior, and can confirm that your provided code snippet will give priority to the titleLocKey when a translation is provided. However, I'm not sure if this is the intended behavior. That being said, I'll notify an engineer and see what we can do here.

[argzdev]

Hi @GP4cK, I've received an update from our engineers. It looks like this is working as intended.

The proper usage of this is to supply either the title or the localized title, not both.

That being said, since this is resolved, I'll close this issue now. Thanks!

[GP4cK]

Hi @argzdev thanks for investigating. Could we challenge the current behaviour? Would it really break things if we accepted the change I propose?

The reason is: right now, if we make use of the localized title, if the user hasn't updated the app, they will receive a blank notification. If we don't want that to happen, it means we need to track which version of the app the user has installed on their device + track in the code which localized string is available in which version etc. That's a lot of extra work which could be avoided...

[argzdev]

Hi @GP4cK. This was discussed with the product team, but was confirmed that this behavior has been like this since 2017. Currently, they have no plans of changing the behavior. So what I can do for now is reopen this and mark this as a feature request, then our engineers can take a look on the use case again on a latter time, and hopefully reconsider this.

I understand that this may take sometime for our engineers to discuss further. If this is really something you need right now, then I'd recommend you to take a look at our Publishing section. You can clone a copy of the SDK, make your changes on the firebase messaging component, publish and link your local copy of the sdk to your app. Hopefully that helps, Thanks!

[GP4cK]

Thanks for the consideration. Fingers crossed then ;)

[argzdev]

By the way, another suggestion from our engineers:

One thing to consider is that throughout an application life cycle there are multiple times when an app population needs to update to avoid breaking. For future proofing, you could make use of Firebase In-app messaging to nudge your users to install updates too.

I think this would be helpful tip!

[Nikolas253]

The current implementation prioritizes returning the unlocalized string (getString(key)) before attempting to fetch the localized version (getLocalizedString(resources, packageName, key)). This behavior is problematic when both a default (unlocalized) and a localized string are available because it doesn't fully utilize the localization capabilities that Android offers, particularly in multilingual environments. Ideally, the method should first attempt to fetch and return the localized string if available, and only fall back to the unlocalized string if the localized one is not found.