How to set a custom locale?

English
#1

I like to set my default locale to a particular setting, the most important requirements:

  • number format with decimal dots (not comma)
  • date format dd-mm-yyyy (or possibly yyyy-mm-dd)

Ideally, I wish it is possible to set both setting individually, or that LibreOffice follows the locale settings of my operating system (MacOS):

Screenshot 2025-12-24 at 17.22.42
Screenshot 2025-12-24 at 17.22.42922×896 108 KB

(screenshot of my MacOS locale settings)

Sadly, I only found the Settings > Languages and Locales > General in LibreOffice, which forces me to make changes to all locales (date format, number format, etc.) at the same time.

Is there a way to set the above settings individually? Perhaps with a work-around?

So far, I was thinking about:

  • Set the locale to English (so I get a decimal dot), and in Calc, individually change the formatting for each cell with dates. I works, and I appreciate that LibreOffice allows me to set the locale for each cell individually, but it is inconvenient. That’s why I like to set a better default.
  • Find some way that allows me to set the number format individually from the date format. I don’t mind altering config files outside the GUI, if that’s what it takes.
  • Find if there is a locale in some other language that happens to adhere to my above requirements (even if that means picking a language I do not understand). If this is the recommended approach, is there a comprehensive overview of all locales along with their date format and number formats?
  • Create my own locale settings. Sadly, I have not found out how (I only came across the Localization Guide, but that is about adding language support for the LibreOffice GUI).

Any suggestion for the best approach?

(Bug report #46448 seems to confirm that LO has an antiquated locale config that enforces a direct relation between language, number format, and date format upon its users, but I am still hoping for a work-around).

#2

All locales accept YYYY-MM-DD as date

You could set your Locale setting to English (UK) which will give you D/M/Y, and a decimal dot; you would need to set Euro. You could set English (Ireland) if you didn’t feel like setting Euro separately as currency. You also need to set default document to the same on the same page of Options

You could instead set it to English (Canada) which shows the date in the formula bar in ISO format

1 Like
#3

Locale_25-8.ods (43.7 KB)

List of locales generated from version 25.8

1 Like
#4

Thanks! That was very useful!

#5

A bit weird answer from EarnestAl. Is this AI perhaps?

I didn’t really care about the input or currency, as you could alter the default independent of the locale region. But thanks to Villeroy’s document, I found that Canada has a acceptable default.

It’s not what I was looking for (“31-12-2025” and “12 345.56”), but it will have to do.

START_OF_RANT
It is really too bad that LibreOffice is so inflexible and seems to be stuck in the 1990s. Because the POSIX concept of setlocale() and LC_* parameters was introduced in 1989 System V Release 4 and 1993 4.4BSD. Thankfully, operating systems like MacOS and Windows moved on and nowadays (although finally since about 5-10 years) give users the freedom to pick and choose the different aspects of locales (number format, date format, 12/24 clock, metric/imperial, etc.), rather then the antiquated strict regional mapping that LibreOffice still seems stuck with – as if every person in a region must have the same preferences.
END_OF_RANT

#6

If the software follows the standards set by the relevant authorities in each country then someone receiving a document knows that the date is in a certain format and won’t read a month as a day not confuse a thousands separator with a decimal point.

As we progress we get more consistency in formats, not less. The alternative is confusion

#7

Hey, remember this is open source. So YOU are allowed to change this.
.

He may use one, if he wishes, but broaden your view. Not everybody will use new names, when software is using their names. I met an Alexa last week.

#8

No, definitely not!
By the way, his nickname is capitalised: EARNESTAL

#9

A joke?

Many Canadians (e.g.) need to correspond with US people and companies.
Their “local date format” is ISO 8601, but if they use it in US exchange there will be confusion. If they adapt to silly MM/DD/YY they betray reason and surrender to power. UK users will also be confused because they think DD/MM/YY is the correct way to communicate dates.

In short: We haven’t too little “flexibility” but too little respect for global standards.
Thousands separators are a special case: The two variants actually in use are exactly those which are explicitly deprecated by ISO. The recommended small space is NOT supported by LibreOffice (and lots of software).
Are we crazy? How could you doubt.

And advice for the OQer: Use locale English(Canada). It’s roughly reasonable.

Concerning paper sizes see How to use a specific paper size? - #5 by Lupp.

...

Also: https://wiki.documentfoundation.org/LibreOffice_Localization_Guide/Adding_a_New_Language_or_Locale. (I never did so myself.)

#10

Seens @MacFreek could request mc-FR for his own purpose. (I would go more for us-us to represent user-settings not necessarily understood elsewhere…

#11

@EarnestAl - I do apologize for calling you an AI. That was uncalled for, and does not justice when you spend your free time helping people. Let me reiterate that I did appreciate your suggestion to use en_CA. So: thanks on this Christmas day!

That said, I stand by my main point that following governmental rules still implies that the preferences of individual people follow exactly what the government says, and I don’t think that is true.

There are sometimes good reasons to deviate from regional standards. For example, in my country the official time designation for half past two in Dutch is “13.30”, but since most software confuses that for the 13.3 decimal number (even though that would be 13,3 here), nearly all software (including LibreOffice) deviates from that standard and uses the more international “13:30” instead. I know some language “affectionados” who really insist to use “13.30 u”, while I prefer the more common “13:30” instead. Everyone their own preferences, I’d say!

And @Wanderer - you are right that this is open source. I did try to look into details, and did find i18npool/source/localedata/data - core - Gitiles, but in my experience, when starting with such software, it is better to get to first understand the software by using it, and when contributing code patches to start small. But I encoureage everyone to who likes to see this fixes, to discuss in 46448 – Allow custom locale settings for decimal separator, group separator, default date and time formats what the best approach would be.

#12

That would create confusion again and again.

to apply ISO standards.
We shouldn’t try to globalize everything except clear information and communication.

Of course, this shouldn’t disallow to develop (enhance) the standards themselves.
Just fight particularism! Or would you want to study Bangla scripts or old Chinese tradition in giving dates because you get a letter twice in a year from far east.
There is a problem with “culture-neutral” standards, of course, but we shouldn’t turn the clock backwards insofar.

Lupp, grafik
(To help you understand: That’s grafik - Gregorian calendar still.)

#13

Hi Lupp,

I’m afraid I do not understand your point. There are different locales in use, and I do see that changing anytime soon (but I do support you, if you want to convert the USA to metric system and A4 papers!). And yes, we already compromise. For one thing, we converse in English, not my native language. So what do you mean with "turn the clock backwards?’.

My point is that people have their own preferences, see the examples in my above posts. And the fact is that LibreOffice does a awesome job in support a lot of locales. It does support the number format that I want, and it does support the date format that I want. My only complaint is that if I pick a certain date format, LibreOffice forces me to change the number format at the same time. That is weird to me.

PS: And I don’t mind the occasional translation between currencies, temperatures, or here: to translate a low resolution image containing “Bangla script” into Bengali Unicode codepoints ২৫-১২-২০২৫, and then realising it is just Bengali digits for 25-12-2025.

#14

We may have this in common.

  • I’m also not a native speaker of English, but a German living in Germany.
  • I never use a German UI or locale. Choice is UI with en (UK), locale en(Canda).
  • Despite my very limited capacities concerning foreign languages, I think we (Europeans) need English as a means of information and discussion. Other languages will not fill the gap.

Now to our LibO locales again.

  • They are too many. However, we can bear with this.
  • But “localisation” of formats needed for reliable general communication is bad evil.
  • The default for dates should always (basically) be ISO 8601.
  • One of the problems is that we can’t switch off automatic formatting. (This not only for dates or TOD!). So called “percentage” format is a mess, e.g.
    If automatic number formats should be maintained at all, the recognition patterns as well as the formats should not be a matter of the locale, but of the CellStyle. For Writer at least respective TextField styles would be needed.
  • Concerning dates again the representation by numbers is problematic, at least as long as different NullDates are in use.
  • Beyond the NullDate thing there is the fact, that Office software lies fundamentally about dates because they are ambiguous as long as the TimeZone isn’t included.
  • In short: Dates and Date-Time values must either be UTC or contain the offset from UTC. Since UTC itself will not be established as the global time standard, this can best be achieved using textual representation.
  • However, textual D-T representations must be accepted as operands for related calculations. Think of “D-T_2 - D-T_1 ===> duration”.

Recently I made a spreadsheet document with macros for watching the european autumn time-shift and for the demonstration of how I would like to work with globally unambiguous D-T representations.
See attachment.
modifiedZoneTimeRecording.ods (49.2 KB)

Sorry for the length. Sorry for the bad English.

#15

No. Better to use local standards than to create different new formats because you like them.
Best to always use ISO standard but change is slow

#16

Creating new “local” formats is exactly what I never would do if there is a globally understood (hopefully accepted) standard.
However, also ISO defines some formats exclusively regarding the needs of IT-based textual exchange (as they were some time ago). E.g. there is the separator “T” between date and TOD.
I take the liberty to replace it by a space for better human readability. The intervention is minimal. I never experienced a misunderstanding.
Also see:
disask_130332_14_AutomaticFormatting.ods (15.7 KB)

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.