strict countryCode problem

[bbsmartc]

countryCode is the system region option which can be changed by the user, lots of users would set this region to where he lives. for example, in my system(macOS) language is en, my region is chinese, then my deviceLocale is en_CN. i think countryCode is designed to be used for precisely specifying the language texts for each region. since user option of region can not be expected as in a range, it can be any option, but it's impossible to supply language texts for all regions (hundreds of countries). i think, it' better to fallback to the same language without country code first, then the global fallback option.
For example, fallback locale is zh_CN(any other locale), when en_FR.json(a user who uses English and lives in France) is not found, it will fallback to zh_CN, but actually it's better to fallback to en.json(the same language without country code)

For a temporary solution, i use Locale('en') instead of Locale('en', 'US') and set useOnlyLangCode: true.

• use Locale('en'), because the countryCode==null will make the locale.supports(anotherLocale) skips the countryCode check (i think it's better to skip this check by useOnlyLangCode == true)
• useOnlyLangCode: true to make it loading the en.json instead of en_REGION.json

But in this solution, it's not possible to specify the language texts for each region, for example, en_US, en_GB

[bw-flagship]

Thanks for describing this issue, it definitely makes sense.
Let me rephrase:

Given that en_US and zh_CN are the supported languages and zh_CN is the fallback language.
A user has en_FR as its device locale.

Right now, the fallback zh_CN would be used.

It would be better to check if there is any supported locale that matches the language, in this case en_US, and use this.

It would be great if you submit a PR for this! :)

[bbsmartc]

Thanks for describing this issue, it definitely makes sense. Let me rephrase:

Given that en_US and zh_CN are the supported languages and zh_CN is the fallback language. A user has en_FR as its device locale.

Right now, the fallback zh_CN would be used.

It would be better to check if there is any supported locale that matches the language, in this case en_US, and use this.

It would be great if you submit a PR for this! :)

sorry for not being able to submit a PR for this issue, not familiar with the code and really have no time to completely figure this out and test. Another 2 PRs of simple modification had been submitted, and thanks for your work in this repo, which did help a lot