Fix broken ENV variables for detailed settings

This fixes the cause for:
BUG: 176650
And seems also related to:
CCBUG: 327757

On my setup I had German for the region and detailed settings selected. To reproduce the KRunner bug I updated the region to India and the displayed example values look as expected:

But the values from the detailes config are not adjusted and persists after logout/reboot.

The printenv command shows the following output:

LC_MEASUREMENT=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LANG=en_IN.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
LANGUAGE=
LC_TELEPHONE=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_TIME=de_DE.UTF-8

You can see that the LANG value got correctly set, but the detailed settings are not up to date.

With this patch we are using the value from the “Region” combo box for the “Detailed Settings” if they are disabled. Exceptions are the LC_COLLATE value. This defaults to “No Change” and because of that we don’t set a default. Also the LC_CTYPE is only set if explicitly defined in the config.

With this patch applied the printenv output looks different:

LC_MEASUREMENT=en_IN.UTF-8
LC_PAPER=de_DE.UTF-8
LC_MONETARY=en_IN.UTF-8
LANG=en_IN.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_NUMERIC=en_IN.UTF-8
LANGUAGE=
LC_TELEPHONE=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_TIME=en_IN.UTF-8

With this change the date format in for example the calendar widget is correctly used and the converter runner suggests the local currency in addition to the most common ones:

I am not entirely sure about the LC_PAPER, LC_TELEPHONE , LC_ADDRESS and LC_IDENTIFICATION values. They don’t have an explicit GUI options. IMO it would make sense to check if they exist in the config and use the LANG as a fallback value, regardless if the useDetailed entry is written.

PS: The useDetailed entry is only used to determine if we have the checkbox “Detailed Settings” enabled. It was ignored when loading the config. In this MR this entry gets used and if it is set to false we don’t use the fallback. IMO the name is misleading and ignoring this value as it was done before would make the code a bit simpler.

This doesn't seem to be caused by but it seems worth mentioning the patch which wrote the initial logic:

https://phabricator.kde.org/D25612

@apol @ngraham