The number of possible combinations is indeed huge, and that is why the actual set is encoded in a file in the user’s home directory. Every app can/should consult this file if it does something dependent on those settings.
There is a limited set of combinations that is built into the Settings app.
When a user selects a locale by giving a language, the Settings app just copies one of those pre-conceived sets to the settings file.
Here is a shot of a part of the MacOS equivalent file on my computer:
As you can see, this in an XML file, and it has sections for each individual setting. It is fairly long, I chose the part with the date format, which happens to be followed by that for the number format. Clearly I can change those things any way I like, provided I know that key 0 means decimal separator in numbers and key 10 means decimal separator in currency values (and they may be different).
A little further down you can see my language settings.
Any of these can be changed separately, if you know where the file sits and if you have write-privileges to it. That is tedious to do, and not something a computing-challenged user should try. So there is a GUI interface for the contents of this file.
For smartphones with Android, the simplistic solution has been to allow only a choice of language. This choice then causes Settings to copy a pre-fabricated file into that settings file. Obviously it is somewhat more complex to provide more flexibility, especially on smartphones.
The difficulty of maintaining all the individual pre-fabricated files still exists.
In fact, considering it more carefully, I think it would be much less of a maintenance problem at the developer’s side, if the user had to set every item themselves! Here is why:
Situation (1): there are no pre-fabricated locale files, only the active one, there is a Settings app that lets you set all the values individually through a GUI interface. Now the user has to go through every setting before using the phone. But if something is added, e.g. ”preferred astrological system”, then only the app has to change.
Situation (2): there are hundreds of pre-fabricated locale files, the Settings app lets you choose one. But now if something changes, all the hundreds of pre-fabricated locale files have to be changed, and potentially more have to be written. Indeed, I’m pretty certain that in the early days there was no English(Switzerland), only French(Switzerland), German(Switzerland) and Italian(Switzerland). So at some point someone at Google or FairPhone had to build that one. In the screenshot you can see at the bottom AppleLocale being “en_FR” and I can remember the days when that did not exist(*).
Situation (1) is surely what the Android developers have in their toolbox, because that’s how they write the pre-fabricated combinations.
Situation(2) is just a marketing simplification. I agree fully that that simplification is a great relief to 95% or more of the users, because they do not have to check every single setting. And of course that’s also how I myself start when I get a new device: the bulk can be set by copying one of those pre-fabricated combinations.
But at the developer’s side, situation(2) caused them a maintenance problem, while they could anyway not get rid of situation(1).
What I would like is to have an app that is the equivalent of what the developers have. Or access to that XML file, wherever it is on Android.
There is no complication involved, it’s all already there anyway.
Plus I carry around all those hundreds of pre-fabricated locale files for no purpose.
Robert.
(*) I can also remember the day when Håkon Lie told me of i18n, his abbreviation for the word “internationalisation”, i.e. “i” followed by 18 letters and then “n”. That was in the early days of the web consortium, 1995 or so.