Uses system default locale for text rendering when preferred locale isn't supported - #195997

@chunhtai can you give this a look please? I thought you you since you have experience in both CJK languages and the framework. I've tried to make the description clear, let me know if you want to chat about it.

If we really want to do something for the default, then probably we need a way to tell if the app is using default locale and only pass in null in that case, but I am not sure whether that worth it though.

Like keeping the locale null, and only resolving as the default (en_US) when it's used. We could do that but it would require a lot of distributed places to edit to make it resolves correctly. Or we could introduce a new type, OptionalLocale which would make it easier to make sure we got it correct.

Gut check: the fact that someone developing an app in Chinese, doesn't specify anything, runs it, and gets Japanese characters just seems bad to me. @chunhtai , am I overestimating what a problem that is? The screenshots kind of show the Japanese characters as being muddy. I wondered if they were muddy because they are more rare in Japanese.

the fact that someone developing an app in Chinese, doesn't specify anything, runs it, and gets Japanese characters just seems bad to me

This is only because the OS decide the render chinese in en-US as japanese and Chinese if no locale supplied. To me that sounds like a platform bug, but I guess we probably need to do something here.

require a lot of distributed places to edit to make it resolves correctly.

I think your current approach is fine, just need a few adjustment.

We should make the API public since I imagine people who don't use Text widget will still need to access the new field, and we can probably put the new fields in existing class like Localization or WidgetsApp.

Locale locale = null;
if(! Localizations.isApplicationLevelOf(context) || !Localizations.noDefaults(context)) {
  locale = Localizations.maybeLocaleOf(context);
}

return RenderParagraph(
  locale: locale,
)

This example remove the condition where we check whether the current locale matches fallback because I worry that we may run into a opposite situation where people wants to send the resolved locale over to text painter because the app is rendered in that locale. I think it is probably better if the logic is consistence, and it will be up to developer to either use a Localization.override for a subtree or using DefaultTextStyle to override the locale in textstyle. WDYT?

This pull request contains changes to Material or Cupertino, which are currently frozen in this repository.

Changes should be made in material_ui and/or cupertino_ui in the flutter/packages repository.

Please refer to #188444 for instructions.

This example remove the condition where we check whether the current locale matches fallback because I worry that we may run into a opposite situation where people wants to send the resolved locale over to text painter because the app is rendered in that locale. I think it is probably better if the logic is consistence, and it will be up to developer to either use a Localization.override for a subtree or using DefaultTextStyle to override the locale in textstyle. WDYT?

@chunhtai I'm kind of out of my element here. I trust your opinion on the matter. I've updated it so that we explicitly keep track wether we are using the default locale or not. It can be overwritten with Localizations.override. Is this what you had in mind? It seems to mirror what we are doing with IsApplicationLevel. PTAL.

I've updated it so that we explicitly keep track wether we are using the default locale or not. It can be overwritten with Localizations.override. Is this what you had in mind?

yup that sounds good to me.

i wrote the example very quick so it seems like we don't really need the isapplicationLevel. if you can do it with one new api then I think it is fine.

@chunhtai okay, sgtm. It's ready for review when you have a chance (I can't rerequest in the current state)

left two comments, the approach LGTM