jclulow: completely fair. There's probably *already* some banking software to have hit the 2038 bug

though banking software is more likely to use COBOL date formats than those based on the Unix Epoch

who

(sorry)

Yeah, I would not be using time(2) or ctime(3C) for anything where I actually cared about time, haha

Release r151054 (LTS/stable) is available - omnios.org/article/r54

did some digging into libstc++ locale support. The "generic" code we use today throws exceptions on contact with a non-C locale facet. Looks like we're about five xlocale.h *_l entrypoints away from being able to use the "dragonfly" libstdc++ locale code.

(motivated by seeing my gnucash port crash unless LC_ALL=C)

looks like: strtof_l strtod_l strtold_l localeconv_l wcsftime_l

sommerfeld: illumos.org/issues/7354

There was some discussion around some of those in the past. If those are useful, it probably wouldn't be too bad to look at.

this reminds me, I was wondering a while ago if we have translation strings for system messages somewhere?

yes

we do create po files (./proto/root_i386/usr/lib/locale/C/LC_MESSAGES/) but thats about it.

but nothing besides C, or did I miss that?

there are no translations, no

i'm guessing those were never released back in the day?

(i.e. we'd had to do the work ourselves)

probably. I would not really expect there to be many anyhow...

i'd have thought solaris would have had a fair number of translations, but it's also not something i ever had to look into...

yep, if we had old ones that were just a bit outdated it might have been fun to get any new strings done - but starting from scratch looks a lot more daunting

i thought someone mentioned there was a site (or sites) where you could pay people to do the translation (though not sure how expensive or how good the results would be)

Yeah, I'll take a look at adding those five functions (a first glance suggests it shouldn't be hard).

or i suppose (stepping into a minefield here) we could see how well chatgpt or the like does as an initial starting point

(there's probably other considerations we'd need to look at if we wanted to seriously entertain the latter)

yea, s11 definitely has them for de_* but ... then again, once done, the translations will last long time considering the rate of changes we have;)

i mean, even though my german and spanish is both limited and absolutely horrible, I'd like to see us have translations since I think it'd reduce a potential barrier for people that are interested

not sure about the possible copyright claims related to AI;)

so not something i felt there was much I could do to help there..

yeah, that'd be the big concern since it seems like the law on that (at least in the US) is far from settled

also I think we still have hidden bugs due to gettext() masking the format strings

jbk: yeah, chances are good that a LLM would just regurgitate another OS's copyrighted translation of the same error message.

or well, produce output indistinguishable from another OS's copyrighted translation..

.. but then so might a human translator..

yeah, i can't imagine that in least some cases, there's going only be a small (even 1) number of correct translations

e.g. I'm guessing there aren't many ways to say 'File not found' in many languages

One rathole I went down for the gnucash port was around lconv->*grouping. As best I can tell there are 4 values for "grouping" that are actually used ("" - no grouping, "\177" - no grouping, "\003" - every 3 digits used in most of the world, "\003\002" - south asian 1,00,00,000.00). Some systems have "" in the C locale. We have "\177", and I belive so does FreeBSD. MacOS and Linux have "".

Lots of mechanism for only a couple different variants.

jbk: plus there's the matter of providing sufficient context to translators so they understand that "file" isn't referring to a rasp-like woodworking tool or a line of people or animals one behind each other...

Filed illumos.org/issues/17416

oooh

Illumos-related dad joke of the day... realtime audio production fork of OmniOS:ΩniOS...

I love a good dad joke, but I'm missing the subtlety here beyond s/Om/{Ohm,Ω}/g

danmcd: perhaps there's some sort of impedance to your sense of humor..

oh, oh no

I thought it was a music-software reference, but my music-software pointer is uninitialized so SEGV.

richlowe: okay, should __EXTENSIONS__ imply _LCONV_C99 (in <iso/locale_iso.h>, included by <locale.h>) ?

I'd think it should..

Hm, I think so.

I'll make that part of 17416

__EXTENSIONS__ on its is probably insufficient.

*on its own

That is C89 + extensions should probably not see it?

so ((defined(_STRICT_STDC) || defined(__EXTENSIONS__)) && defined(_STDC_C99)) || defined(_LCONV_C99)?

Maybe? Let me go read a few docs.

thanks for taking a look..

No problem. I had had some notes to look at those a while back so appreciate you looking at adding those functions.

I have them prototyped to the point where I'm running a nightly.

It was not hard.

So thinking on it a bit more, the C89 specific bit makes me a bit uncertain. A part of me thinks it kind of wants to be just #if !defined(_STRICT_SYMBOLS) || defined(_STDC_C99) || defined(_LCONV_C99).

That would mean non-strict C89 does see it. It also means that older POSIX will not see it, but I think that's a bit to go double check is who first introduced the extensions.

The new stuff would just be the simple if !defined _STRICT_SYMBOLS.

Yeah, I think seeing it in C89 in a non-strict mode is probably... fine.

new functions land in xlocale.h which is not in standards-land.

Ah, then you're fine.