Locale & date format

I understand your frustration here. In my case IE will do the job, because it will give me Euro, metric and correct grouping and decimal. (As expected because it is my locale). It will also stops apps and websites constantly sending me to the UK version.

If there was improved customisation of locale per your requirements it would also work for me in cases when handset makers decide to cull locales they consider to be unimportant.

I don’t know if this is just a function of the Beta A13, I’ve lost my A11 FP3 for a few weeks, but there are a lot of English versions ~ dozens.

1 Like

Thanks. Do you know if the Ireland one is in there if you scroll down?
Would be really annoying if they had dozens and the ie one was still missing :smile:

I just tried it and I successfully chose “English (Ireland)”. I’m on the A13 beta as well but I doubt it’s missing in A11.


Doesn’t the rest of it, apart from the way the date is displayed, already work on Android?

I can’t check on stock FPOS right now, but on the AOSP based ROM I’m using there’s English (Germany), that totally gives me what I want, English text and sensible units of measurement :thinking:
(The same is true for my linux systems)

There’s an English (Switzerland) option as well, if that’s what you need.

I confirm that Ireland is in the list (of languages anyway). (Android 13 in FP4)

English (Switzerland) does of course NOT help, since it will set the currency to CHF, not EUR.
I repeat: there is no COUNTRY that has the settings I desire. And I’m not alone. Anyone living in an international environment is likely to run into this problem.
It is so simple to make all settings independent, while at the same time keep the ability to choose a country-package.
It’s not rocket science! We have computers now. Or so it seemed.


That’s a bit, how can I say . . . .

It’s so simple to dig a hole, we have spades, it’s not . . . but who wants to do it? Apparently anyone would at a price, it’s a choice :slight_smile:

Clearly the demand is a bit low

Point taken.

If you need these fine grain controls you probably have to create that language version yourself, I don’t see Google implementing these options any time soon.

There are still systems that let you control that, Linux for example. No idea about the current state on Windows.
But, every additional option comes with maintenance costs, so if 99% of your users are happy with the defaults it makes sense from a business standpoint to remove the rarely used ones.

Doesn’t mean I like it, but that’s generally the reasoning.


Let me make it as clear as possible: these options already exist, and independently. They must, because all a choice of locale does is to set them in a pre-defined pattern.
Previously (macOS, Windows, Android, … ) the user needed to set them each individually.
It is the ability to give predefined ensembles of choices that constituted the extra work of coding to be maintained, not the other way around.
The panels were there anyway. Removing them just pleases the minimalists.
I also understand the “business” reasoning but I don’t think that’s what is at the bottom of it. Rather it’s form over function. “Streamline” everything to the death.
And, I will be happy with getting those settings through some line-mode incantation, or a special app or whatever.
Also, if society wants to be ever more inclusive, then companies should not neglect the minorities. Else we should all start learing Chinese ideograms for writing.
I think my case is about 5%, not 1% but that is open for gathering statistics.
Well, we’ll see. I could learn the specifics of Android and dig my way down, but it simply takes too much effort.
Here is another simple example of the “form over function”: the floor heating controller of our heating system broke, and was replaced with a new one. It has a touch screen etc., but NO indication whatever of the mixing valve position! Why am I not allowed to see that? Purely “form over function”. Needless to say, installation was not without problems, and in this case, it has led to three physical interventions from the company: trucks coming around, hours of technician’s work, …, all of which could have been avoided if the valve’s position had been visible on the screen, even if it had just been a number. But it ”does not look good”, so it was removed.
What cost?


The current implementation has a known set of language, time, unit, currency, etc. combinations. You can test for that.
Compare that to the amount of combinations you get if people can mix and match all of them.

This isn’t only a system problem, apps can declare which languages they support as well. What happens if the language is supported but the way things should be displayed isn’t.
I can think of so many edge cases you’d get by retroactively enabling that option …

I have absolutely no data on this, consider 99% a figure of speech. All I know is that this is the first time this has come up on the forum as far as I can tell, so compared to the many other issues people have with the FP4 it’s probably low priority.

Don’t get me wrong, I’d like the clock etc. in the proper format as well, which is why I generally use systems that let me configure everything, but hoping for Google to add more options seems like a futile endeavor, if the last few years are any indication.

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.


(*) 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.

1 Like

I’m not talking about maintaining the language files, I’m talking about testing all the combinations. Before you get to use the phone in your hand it has to go through an enormous amount of automated tests, that’s where the near infinite number of possible combinations becomes a problem.

This discussion is going nowhere, you don’t have to explain to me how it could be done, I know that, that was never the question. It cleary is possible, there are systems that let you choose finer grained options, Android isn’t one of them.

At the end of the day the proper place to get this implemented is upstream. I don’t see anything happening on the Fairphone side, they are struggling enough to keep the phone running as it is.

Anyways, have a nice weekend, I’m out.

1 Like

Yes you are obviously right.
(I did not know whether we were on the same wavelength).
The millions of combinations do not have to be tested at all anyway.
But OK, and I’m out too.
Have fun.

1 Like

Indeed, that does exist in stock A12, but unfortunately there is no “English (France)”, probably because French don’t speak English, and there are no US military bases here.

To add my unrequested 2 cents worth to the discussion, adding a “custom” locale would neither break the programmers’ backs, nor confuse average customers to an early death.

Now I admit it would be rarely used, but then so are sunglasses, bathing suits, extinguishers, handkerchiefs… Yet we have them.
Being country-independent is necessary for some people, especially in Europe where some countries are so small you can cross them on foot in a day… :stuck_out_tongue_winking_eye: :laughing:

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.