search

aissat / easy_localization

Easy and Fast internationalizing your Flutter Apps
https://pub.dev/packages/easy_localization
MIT License
908 stars 325 forks source link

strict countryCode problem #674

Closed bbsmartc closed 3 months ago

bbsmartc commented 5 months ago

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.

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

bw-flagship commented 5 months ago

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 commented 5 months ago

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