Reported language doesn't always match reality

[ueman]

Platform

Flutter Mobile

Obfuscation

Disabled

Debug Info

Disabled

Doctor

Unrelated to the Dart/Flutter version

Version

7.5.0

Steps to Reproduce

1. Restrict the language manually via the parameters of MaterialApp/CupertinoApp/WidgetsApp as seen in the code snippet. Restrict it to a language different than the device language.

MaterialApp(
  supportedLocales: supportedLocales,
  locale: selectedLocale,
);

2. Cause an error
3. Sentry reports the device language, not the manual set one.

Expected Result

I would expect the language to be the one set in the MaterialApp.

Actual Result

Device language is reported.

Are you willing to submit a PR?

None

[marandaneto]

It's not specified if it should be the device's language or the screen's language, maybe we need both.
https://develop.sentry.dev/sdk/event-payloads/contexts/#culture-context
Not sure if it's a bug though, maybe adding a new field for the screen's language makes more sense? I believe both would be important for solving language bugs.

[ueman]

Not sure if it's a bug though, maybe adding a new field for the screen's language makes more sense? I believe both would be important for solving language bugs.

I agree, that sounds reasonable.

[buenaflor]

One way for us to retrieve the locale would be to use a navigatorKey

// somewhere in the SDK
GlobalKey<NavigatorState> sentryNavigatorKey = GlobalKey<NavigatorState>();

// your app
MaterialApp(
  navigatorKey: sentryNavigatorKey,
//...
)

Then somwhere in the SDK we can do

final context = sentryNavigatorKey.currentContext;
final screenLocale = Localizations.localeOf(context);
// ... add it to context

@ueman what do you think? any concerns with this approach?

[ueman]

No concerns on my side, but that kinda goes against the design philosophy of the SDKs of a very simple configuration. Not sure though if that's a blocker or concern for you.

[buenaflor]

Indeed, ideally adding a navigatorKey shouldn't be needed but I'm not sure if there are other ways to retrieve the BuildContext without user intervention unless I missed something.

[ueman]

Unfortunately, I also don't see any way of doing that.

[denrase]

We already use a global key to extract the current context for the ScreenshotWidget. Does introducing a more generic SentryWidget which could be used for both and also be extended in the future make sense? Since we are already recommending that users add it around the App widget.

[ueman]

We already use a global key to extract the current context for the ScreenshotWidget. Does introducing a more generic SentryWidget which could be used for both and also be extended in the future make sense? Since we are already recommending that users add it around the App widget.

I think that's too high in the widget tree to get the localization, but it's actually a good hint

[buenaflor]

Just tested it for confirmation and it seems so, it would be too high in the tree.