Scenarios: Fix locale test on hosts with several languages - #190821
Merged
Conversation
`testNoLocalePrepend` asserted that the host has exactly one preferred
language:
NSArray<NSString*>* preferredLocales = [NSLocale preferredLanguages];
XCTAssertEqual(preferredLocales.count, 1);
and then built the expected value from `preferredLocales.firstObject`
alone. The scenario publishes the whole list dart:ui received as its
semantics label, so on a host configured with more than one language,
the app will report a list (e.g. `[ja_JP, en_CA]`) while the test looks
for `[ja_JP]`.
The goal is to check that we got the right set of locales, but
hardcoding the count check to one isn't the right way to do it and
causes the test to fail for any developer with more than one language in
their locales list. Given that multilingual developers outnumber
unilingual ones, this is arguably a bug in the test, or at least an
annoyance.
We now build the expected value from every preferred language, joined
the way Dart formats the list, and the count assertion is gone.
Tested on my machine which uses 日本語, by English (Canada), where
dart:ui reports `[ja_JP, en_CA]`.
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates LocalizationInitializationTest.m to handle multiple preferred locales in testNoLocalePrepend instead of assuming a single locale, making the test more robust to different device locale setups. The review feedback suggests formatting pointer declarations in Objective-C to place the asterisk next to the variable name or type parameter inside generics, in accordance with the Google Objective-C Style Guide.
hellohuanlin
approved these changes
Aug 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
testNoLocalePrependasserted that the host has exactly one preferred language:and then built the expected value from
preferredLocales.firstObjectalone. The scenario publishes the whole list dart:ui received as its semantics label, so on a host configured with more than one language, the app will report a list (e.g.[ja_JP, en_CA]) while the test looks for[ja_JP].The goal is to check that we got the right set of locales, but hardcoding the count check to one isn't the right way to do it and causes the test to fail for any developer with more than one language in their locales list. Given that multilingual developers outnumber unilingual ones, this is arguably a bug in the test, or at least an annoyance.
We now build the expected value from every preferred language, joined the way Dart formats the list, and the count assertion is gone.
Tested on my machine which uses 日本語, by English (Canada), where dart:ui reports
[ja_JP, en_CA].Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.