`$locale` collected different from iOS

[fphilipe]

Version

3.71.2

Steps to Reproduce

We have an iOS and Android app that integrates the respective PostHog SDK.

Our app is available in English and German. In our Mobile Analytics dashboard on PostHog (created using the PostHog template) I see a breakdown of the languages. This breakdown contains many more languages (including country specifier such as ru-RU) than just the two the app runs in.

Digging deeper, I realized that the additional languages only come from Android. On iOS it indeed only reports just the language the app runs in, as can be seen in its source:

if #available(iOS 16.0, macOS 13.0, tvOS 16.0, watchOS 9.0, *) {
    if let languageCode = Locale.current.language.languageCode {
        properties["$locale"] = languageCode.identifier
    }
} else {
    if Locale.current.languageCode != nil {
        properties["$locale"] = Locale.current.languageCode
    }
}

On Android on the other hand you collect the language the device is set to:

posthog-android/posthog-android/src/main/java/com/posthog/android/internal/PostHogAndroidContext.kt

Line 70 in ba36fc5

dynamicContext["\$locale"] = "${Locale.getDefault().language}-${Locale.getDefault().country}"

Expected Result

On Android it should collect just the language that is also used for resource lookup. If my phone is set to de-CH and the app only supports English, I want to see en as the value for the $locale property.

This is how the chart looks filtered by iOS:

Actual Result

This is the same chart filtered by Android:

[dustinbyrne]

Thanks for reporting this. You’re right that Android and iOS behave differently here in two ways:

• Android reads the default locale, which can differ from the language your app displays. iOS uses Locale.current, which accounts for the app’s supported languages and per-app language settings.
• Android includes the country (de-CH), while iOS only sends the language (de). Our property definition describes $locale as the device locale, with examples like en-US and de-DE, so iOS dropping the country is also an inconsistency. That is separate from which language the app actually displays.

We tested an English-only app with a resource context configured for de-CH on Android. Even Android’s app-context locale reports de-CH while the app displays English fallback strings, so it doesn’t look like switching to that API alone will fix this.

For now, you can override $locale with the language your app uses through beforeSend. We tested this with Android SDK 3.71.2 and confirmed that the outgoing events contained the supplied en or de value instead of de-CH. Add it before setting up PostHog:

config.addBeforeSend { event ->
    event.properties?.set("\$locale", currentAppLanguage())
    event
}

Replace currentAppLanguage() with your app’s language getter, returning "en" or "de" for the breakdown you described.

[fphilipe]

Thanks, that's what I'm doing. I rely on a trick to get the locale: I define a string resource language that gets the respective language code as the value in each values-$LANG/strings.xml file.

I think this snippet should work as well:

fun Context.currentLanguageCode(): String {
    val locale: Locale = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
        resources.configuration.locales[0]
    } else {
        @Suppress("DEPRECATION")
        resources.configuration.locale
    }
    return locale.language   // e.g. "en", "de", "fr"
}

[dustinbyrne]

I’ve opened a draft PR to explore this: #832.

The proposed approach matches the user’s language preferences against the app’s declared supported locales. It uses Android’s LocaleConfig API on Android 13+, and reads the same packaged XML directly on Android 6–12. If nothing matches, it uses an explicitly declared default; if that information is unavailable, it keeps today’s behavior.

This is just a proposal. It selects the best supported app language, but won’t necessarily match every displayed string because individual resources can fall back differently.

Does your app declare a localeConfig, manually or through AGP? That would help us check whether this approach covers your setup.

[fphilipe]

Does your app declare a localeConfig, manually or through AGP? That would help us check whether this approach covers your setup.

We declare it manually: android:localeConfig="@xml/locales_config" in the manifest. We don't use AGP generateLocaleConfig.