Exactly what's wrong with locale is a bit complicated.
It came from a time past where the challenges of writing software were quite different. But the world has changed and the way we view and solve certain problems is completely different.

If you use it correctly and you know what you are doing it kind of works even if it is very awkward.
The problem starts when features that have been built around locale, use it in a way that is not transparent.
Formatting algorithms become slower and less efficient to accommodate for changes in locale, despite the fact that the vast majority of application requires a very specific way to format which a change in locale would completely destroy.
For inexperienced programmers it's a trap (one that I have fallen into myself) where an application running on a different environment with a different locale settings would completely break because you did not expect that in certain locales the decimal separate for float numbers is a coma thus ruining your comma separated file, or that time information is printed differently.
Plus, certain features uses a locale that is set globally for your application. You would need to be careful for pieces of code that may change the locale to do something specific, and then forget to change it back thus completely breaking the expectations somewhere else.
To add insult to injury, best practices for localization settings in user interfaces has changed. The default localization settings set on your operating systems in not necessarily how a user running your application would like to use it, plus certain languages have nuances that locale is not able to cover, and in those circumstances if you want to do it write you will end up creating your own localization solution that has nothing to do with locale.
 
So, it is in this position where, a lot of stuff uses it for historical reasons, it has performance downsides, usability downsides, problems with consistency, and if your application is sophisticated enough, you would create your own solution and not even want to use locale.
Hence why it as a solution is on its way out.


-----Original Message-----
From: Std-Discussion <std-discussion-bounces_at_[hidden]p.org> On Behalf Of Daniil Rozanov via Std-Discussion
Sent: Saturday, March 22, 2025 7:27 PM
To: Std Discussion <std-discussion_at_lists.isocpp.org>
Cc: Daniil Rozanov <personal_at_rozanov.info>
Subject: [std-discussion] Why locales are bad?

I've heard many times at all sorts of conferences that locales are broken, that developers write their implementations without locales, and that using std::locale now is an outdated practice. In this regard, I have a few questions about it.

1. What exactly is wrong with locales? Can you just give me link to some article or paper with explanation about it.

2. In that regard, is everything okay with all kinds of std::streambuf and std::stream? Suppose I write a new library that supports c++11 and later. Should I support streams interface (which implicitly uses locales (or I can reimplement whis??)) or is it better to imlement any different interface for I/O operations? I mean, doesn't SG16 do things that will replace std::codecvt. Maybe there is more modern way to support I/O.

3. Is it ok for new code to have I/O classes derived from basic_ios?
More specifically, I want to make some wrap on C library with it's own I/O, which is quite similar to linux api (read, write, getch, etc). Is stream interface still common for that?

Thanks for the explanation, and sorry if this is off-topic.


Daniil Rozanov
--
Std-Discussion mailing list
Std-Discussion_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion