Add Linux support

[proninyaroslav]

std::setlocale is used to get the current locale. Since GNU/Linux and POSIX doesn't provide a standard API for getting the preferred languages, DeviceLocale.getPreferredLocales always returns the current locale. This is stated in the README. The code has been tested and works as expected.

Screenshots:

[proninyaroslav]

@bratan
Please merge it.

[proninyaroslav]

@bratan
Please review this PR

[bratan]

@proninyaroslav - The output is wrong in Ubuntu 22.04

[proninyaroslav]

@bratan
Thank you, I will check it.

[proninyaroslav]

@bratan
Can you provide the output of the locale command (in terminal)? In my case everything works as expected, Ubuntu 22.04 LTS

[bratan]

This is the output of locale:

And the app output:

It's a standard Ubuntu 22.04 LTS installation.

[bratan]

@proninyaroslav - This seems to fix the issue and display correctly the locale:

Is there any downside in using LC_CTYPE instead of LC_ALL?

[proninyaroslav]

@bratan
LC_ALL - set the entire locale generically
LC_CTYPE - set a locale for the ctype and multibyte functions. This controls recognition of upper and lower case, alphabetic or non-alphabetic characters, and so on.

So, LC_ALL environment variable has precedence over any of the other environment variables. It's strange that such an output is even possible, do you use any terminal or IDE to run Flutter? Maybe these variables belong to him? Then it's logical to execute locale inside this environment.

[bratan]

I`ve run the app with VSCode, bash terminal, zsh terminal, same output everywhere.

Basically the issue is that LC_ALL is not set and from what I could find, the solutions are generally to explicitly set LC_ALL in /etc/environment or other places, however this might not be a good solution since it requires manual intervention from the end-user.

[proninyaroslav]

It's also not set in the image that I tested, but I sent you the screenshot above, which shows that it works properly and displays the locale, not something weird like LC_CTYPE=en (which looks more like an incorrectly set LC_ALL variable). This is a weird bug, maybe getting LC_CTYPE would be the only option.

[bratan]

I think one solution would be to get the LC_ALL (so the current implementation) and check if the result starts with LC_CTYPE= and if so, get the LC_CTYPE instead and use that value.

[proninyaroslav]

@bratan
As it turned out from the documentation, if LC_ALL isn't set, setlocale returns a list of all possible categories (LC_*) and its locales:

If the locale argument is a null pointer, the program's current locale setting isn't changed. Instead, setlocale returns a pointer to the string that's associated with the category of the thread's current locale. If the category argument is LC_ALL, the function returns a string that indicates the current setting of each category, separated by semicolons. For example:

LC_COLLATE=en-US;LC_CTYPE=en-US;LC_MONETARY=fr-FR;LC_NUMERIC=en-US;LC_TIME=en-US

So I make this: if LC_ALL isn't set, we iterate through other categories in order of priority until we find one that is set.

[bratan]

@proninyaroslav - Good solution, seems to be working well now. Thanks.