2022-12-16 GnuCash IRC logs
15:05:38 *** gncbot has joined #gnucash
15:06:03 <jralls> @tell gjanssens, Darn it, missed you by a few minutes.
15:06:03 <gncbot> jralls: The operation succeeded.
15:06:12 *** warlord sets mode: +o gncbot
15:06:16 <jralls> @tell gjanssens, Darn it, missed you by a few minutes.
15:06:16 <gncbot> jralls: The operation succeeded.
15:06:37 <warlord> needed to restart supybot to take the irc.gnome -> irc.gimp change
15:16:17 <jralls> @tell gjanssens You got it right about en_DE->de_DE because otherwise the user gets "C"; perhaps when you experimented you briefly forgot that it actually has to be `de_DE.UTF-8`.
15:16:17 <gncbot> jralls: The operation succeeded.
15:31:38 *** gour has quit IRC
15:35:50 <jralls> @tell gjanssens The reporter of bug 798657 wants English strings with German date, number, and currency formatting. This is pretty common. Gnu gettext ignores the locale completely. Its default language is determined by the set of language codes in $LANGUAGES. On macOS that's set from the AppleLanguages list. I expected boost::gettext to wrap GnuGettext, but apparently it doesn't.
15:35:50 <gncbot> jralls: The operation succeeded.
15:41:49 <jralls> @tell gjanssens See libgnucash/core-utils/gnc-locale-utils.cpp to remind yourself about how we set up caches for std::locale and boost_locale based on setlocale(LC_ALL, ""). Note that there are only two uses of LC_MESSAGES, on in gnucash-locale-windows.c where setlocale(LC_MESSAGES, "") is used to *query* the environment locale and once in assistant-hierarchy to retrieve the locale to create a file path. It's not used to
15:41:49 <gncbot> jralls: The operation succeeded.
15:41:50 <jralls> translate anything anywhere.
15:42:06 <jralls> @tell gjanssens translate anything anywhere.
15:42:06 <gncbot> jralls: The operation succeeded.
15:48:08 *** gjanssens has joined #gnucash
15:48:08 *** ChanServ sets mode: +o gjanssens
15:53:58 <jralls> @tell gjanssens boost::locale::translate()'s indirect behavior is intended to use the stream's imbued locale instead of a specified locale; its `str()` function does the translation with a passed-in locale. boost::locale::gettext turns out to be effectively an alias for boost::locale::tranaslate().str().
15:53:58 <gncbot> jralls: The operation succeeded.
15:56:27 <gjanssens> Yeah, that's how I understood now. The alias was news to me though
15:56:27 <gncbot> gjanssens: Sent 40 minutes ago: <jralls> You got it right about en_DE->de_DE because otherwise the user gets C ; perhaps when you experimented you briefly forgot that it actually has to be `de_DE.UTF-8`.
15:56:28 <gncbot> gjanssens: Sent 20 minutes ago: <jralls> The reporter of bug 798657 wants English strings with German date, number, and currency formatting. This is pretty common. Gnu gettext ignores the locale completely. Its default language is determined by the set of language codes in $LANGUAGES. On macOS that's set from the AppleLanguages list. I expected boost::gettext to wrap GnuGettext, but apparently it doesn't.
15:56:29 <gncbot> gjanssens: Sent 14 minutes ago: <jralls> See libgnucash/core-utils/gnc-locale-utils.cpp to remind yourself about how we set up caches for std::locale and boost_locale based on setlocale(LC_ALL, ). Note that there are only two uses of LC_MESSAGES, on in gnucash-locale-windows.c where setlocale(LC_MESSAGES, ) is used to *query* the environment locale and once in assistant-hierarchy to retrieve the locale to create a file path. It's not used to
15:56:30 <gncbot> gjanssens: Sent 14 minutes ago: <jralls> translate anything anywhere.
15:56:31 <gncbot> gjanssens: Sent 2 minutes ago: <jralls> boost::locale::translate()'s indirect behavior is intended to use the stream's imbued locale instead of a specified locale; its `str()` function does the translation with a passed-in locale. boost::locale::gettext turns out to be effectively an alias for boost::locale::tranaslate().str().
16:00:04 <jralls> gjanssens I can poke at making and using LC_MESSAGES different from LC_CURRENCY, LC_NUMERIC, and LC_DATE but I wonder if the effort might be better put into switching to ICU. It works the way mac and windows users expect with full customization of the l18n behavior.
16:01:37 <jralls> Neither is going to happen in time for 4.13 though. s/bl::translate(\(.*\))/_(\1)/ is the best I can do for that.
16:22:15 <gjanssens> I didn't forget about the utf8 requirement, just didn't mention it in text.
16:22:33 <jralls> Hmm, another problem then.
16:23:23 <gjanssens> Yeah it must be.
16:28:33 <jralls> Oh, you said "If I use de_DE as LANG". Did you mean en_DE?
16:34:06 <jralls> Aside from that what do you think of replacing bl::translate and the one bl::gettext with _()? I guess we have to construct a std::string to pass to bl::format...
16:41:49 <jralls> `LANG=de_DE.UTF-8 gnucash-cli --logto=stderr --help` produces the help message in German with no warnings. `LANGUAGES=de gnucash-cli --logto=stderr --help` produces an English help message.
16:42:10 *** gjanssens has quit IRC
17:25:41 *** gjanssens has joined #gnucash
17:25:41 *** ChanServ sets mode: +o gjanssens
17:26:40 <gjanssens> .
17:26:47 <gjanssens> jralls: Yeah I meant en_DE in that context
17:26:57 <gjanssens> I have no strong opinion on what to use for translation.
17:26:59 <gjanssens> The use of bl::translate and bl::gettext was based on the idea that we would eventually move to boost::locale for everything.
17:27:00 <gjanssens> If that's not going to happen, we may just as well unify on a single method like _()
17:27:18 <gjanssens> But as you say for bl::format it needs to become a std::string
17:27:32 <gjanssens> And with that I'm off to bed...
17:27:38 <gjanssens> 'Night!
17:27:45 <jralls> gjanssens, I've now tested that and it works. Goodnight!
17:50:42 *** gjanssens has quit IRC
18:39:25 <chris> jralls: maint->master has lots of conflicts in code that IMO you're more familiar with
18:42:59 <jralls> @tell gjanssens Now for the KDE autocomplete problem I propose to commit your usleep(1000); at gnucash-sheet.c#1839 as I think that's the most specific place that fixes the problem. That will get the KDE users back in business and we can continue to dig into it later.
18:42:59 <gncbot> jralls: The operation succeeded.
18:44:06 <jralls> chris, Probably. I do a maint->master merge after the release so I'll deal with the conflicts then.
18:48:54 <chris> Ok. I'd thought "merge early and often" would minimise cognitive workload when merging
18:49:23 <chris> meanwhile what do we do about investment-lots
18:50:36 <jralls> Is it using any of the options API deprecated in master?
18:51:40 <jralls> Early and often in this case colides with jralls's available bandwidth this weekend. ;-)
18:52:15 <chris> NP I'd mentioned it because I attempted and thought it too difficult for now
18:53:09 <jralls> Which, maint->master or investment-lots report?
18:53:36 <chris> maint->master's conflicts
18:54:00 <jralls> OK.
18:54:59 <chris> re:Investment-lots' option - not sure -- there's a bunch of warnings in master's options
18:55:56 <jralls> Then point him to the new api and tell him to clean it up.
18:58:51 <chris> I meant to say: master still has a bunch of warnings in options; investment-lots may add some more but I can't tell from the noise
18:59:13 <chris> e.g.
18:59:15 <chris> <unknown-location>: warning: possibly unbound variable `GncOptionUIType-TAX_TABLE'
18:59:17 <chris> <unknown-location>: warning: possibly unbound variable `#{999999999.0,}#'
18:59:19 <chris> <unknown-location>: warning: possibly unbound variable `GncOptionUIType-DATE_FORMAT'
19:05:10 <chris> the second warning is a typo
19:06:13 <jralls> And I'd guess the other two are failing to (use-modules (gnucash options)).
19:07:11 <chris> nopes doesn't fix it
19:11:10 <jralls> how about (use-modules (sw_engine)) ?
19:14:40 <jralls> hmm, gncoptionuitype isn't used in the PR so it must be coming from somewhere else. There
19:16:19 <jralls> There's that bandwidth problem again, and next week is pretty busy too.
23:43:34 *** gour has joined #gnucash
23:43:34 *** ChanServ sets mode: +v gour