Re: Localization of date(1) and XFCE
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 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), >
Re: Localization of date(1) and XFCE
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
Re: Localization of date(1) and XFCE
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. XFCE as a third-party application might choose to support it, but that has nothing to do with the base date(1).
Localization of date(1) and XFCE
Hi, Well, i'm using OpenBSD 6.9 on my Thinkpad laptop using XFCE as desktop environment. I started another thread about emojis but here I wanna share an inconsistency I'd like to work out. 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 I've read it happening before but I didn't find the solution. -- ~ffuentes sysadmin texto-plano.xyz
