Thank you for the detailed answer. I'll use this information to talk to xfce devs and the maintainer if they could do anything to keep a consistent experience in OpenBSD.
El June 25, 2021 5:28:00 PM UTC, Ingo Schwarze <schwa...@usta.de> escribió: >Hi, > >Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200: >> On Jun 20 18:58:31, ffuen...@texto-plano.xyz wrote: > >>> I speak Spanish and thus I use a locale called es_CL.UTF-8. XFCE is >fine >>> with it. However, my date is expressed directly as it comes from >date(1). >>> This is confirmed by their docs >>> https://docs.xfce.org/xfce/xfce4-panel/4.16/clock so how do I make >date to >>> work with my language. >>> >>> This is my locale: >>> >>> LANG=es_CL.UTF-8 >>> LC_COLLATE="es_CL.UTF-8" >>> LC_CTYPE="es_CL.UTF-8" >>> LC_MONETARY="es_CL.UTF-8" >>> LC_NUMERIC="es_CL.UTF-8" >>> LC_TIME="es_CL.UTF-8" >>> LC_MESSAGES="es_CL.UTF-8" >>> LC_ALL=es_CL.UTF-8 > >> man locale >> >> Programs in the OpenBSD base system ignore the locale except >> for the character encoding, and it is not recommended to >> use any of these variables except that the following >> non-default setting is supported as an option: >> >> export LC_CTYPE=en_US.UTF-8 >> >> OpenBSD's date(1) ignores your locale setting. > >That's the correct answer, and there are no plans to change that in >the future. > >The reason is that we prioritize simplicity and maintainablity >of the C library, and consequently correctness and security, >over localization of base system facilities. On top of that, >even if you do not take the horrible complication of the library >code that LC_* support would imply into account, LC_* also poses >some security risks from the user perspective, in particular in >system administration and maintenance contexts. Predicatbility >of output, and consistent parsing of input, is more valuable for >low-level work than localization. > >Perspectives may vary, but my personal opinion is that adding all >those LC_* variables to POSIX was a mistake. The C library is >not a reasonable place to handle higly specialized and highly >complicated topics like localization. They belong into >specialized programs like typesettung software, UI libraries >and the like, not into a general-purpose operating system. > >In general, we try to follow POSIX because standardization and >portability have significant advantages. But there are limits. >If standards requirements are too bad, we may decide to ignore >them in some (rare) cases. Hence, on OpenBSD, you can rely on >predictable output from strftime(3) and on predictable parsing >by strptime(3). > >All this is mostly documented, for example: > > STRFTIME(3) Library Functions Manual > [...] > CAVEATS > On systems other than OpenBSD, the LC_TIME locale(1) category can > cause erratic output; see CAVEATS in setlocale(3) for details. > > SETLOCALE(3) Library Functions Manual > [...] > CAVEATS > On systems other than OpenBSD, calling setlocale() or uselocale(3) > with a category other than LC_CTYPE can cause erratic behaviour > of many library functions. For security reasons, make sure > that portable programs only use LC_CTYPE. > > For example, the following functions may be affected. The > list is probably incomplete. For example, additional library > functions may be impacted if they directly or indirectly call > affected functions, or if they attempt to imitate aspects of > their behaviour. Functions that are not standardized may be > affected too. > > LC_COLLATE > glob(3), strcoll(3), strxfrm(3), wcscoll(3), wcsxfrm(3), > and the functions documented in regexec(3) > > LC_MESSAGES > catgets(3), catopen(3), nl_langinfo(3), perror(3), > psignal(3), strerror(3), strsignal(3), and the functions > documented in err(3) > > LC_MONETARY > localeconv(3), nl_langinfo(3), strfmon() > > LC_NUMERIC > atof(3), localeconv(3), nl_langinfo(3), strfmon(), and > the functions documented in printf(3), scanf(3), > strtod(3), wcstod(3), wprintf(3), wscanf(3). This > category is particularly dangerous because it can cause > bugs in the parsing and formatting of numbers, for > example failures to recognize or properly write decimal > points. > > LC_TIME > getdate(), nl_langinfo(3), strftime(3), strptime(3). > Similarly, this is prone to causing bugs in the parsing > and formatting of date strings. > > LC_CTYPE > On systems other than OpenBSD, this category may affect > the behaviour of additional functions, for example: > btowc(3), isalnum(3), isalpha(3), isblank(3), iscntrl(3), > isdigit(3), isgraph(3), islower(3), isprint(3), > ispunct(3), isspace(3), isupper(3), isxdigit(3), > mbsinit(3), strcasecmp(3), strcoll(3), strxfrm(3), > tolower(3), toupper(3), vis(3), wcscoll(3), wcsxfrm(3), > wctob(3) > >Yours, > Ingo -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
