Created attachment 370294 [details] Screenshot of calendar with current month in 2.7.8 the calendar widget shows the current month as “(null)”. All other months are fine.
This doesn't appear to be an issue using DD/MM/CCYY (eng_au) locale as it displays March as expected for the current month. So presumably date format related ?
Created attachment 370319 [details] eng-au screenshot showing current month displayed correctly.
Indeed, works correctly for en_US and fr_FR. What are your locale settings?
Mo, Di, Mi ... could be de. We do not translate the month names. So another language package of the reporter's system might be broken.
That would probably be Gtk+-3.0.
My language setting ist Deutsch-Deutschland, which should translate to de_DE. In terminal the LANG variable is set to de_DE.utf8. But when starting the App directly from the terminal the current month shows just fine. Unsetting LANG does make the error happen again even when started from the terminal.
Only when the error occurs the following warning is written into the trace file: * 08:26:02 WARN <GLib> gdate.c:2526Error converting results of strftime to UTF-8: Invalid byte sequence in conversion input * 08:26:02 WARN <GLib> gdate.c:2526Error converting results of strftime to UTF-8: Invalid byte sequence in conversion input * 08:26:02 WARN <GLib> gdate.c:2526Error converting results of strftime to UTF-8: Invalid byte sequence in conversion input * 08:26:02 CRIT <Pango> pango_layout_set_text: assertion 'length == 0 || text != NULL' failed * 08:26:02 CRIT <Pango> pango_layout_set_text: assertion 'length == 0 || text != NULL' failed * 08:26:03 CRIT <Pango> pango_layout_set_text: assertion 'length == 0 || text != NULL' failed * 08:26:03 CRIT <Pango> pango_layout_set_text: assertion 'length == 0 || text != NULL' failed
Ahah! I can now replicate by setting the region in system prefs to Germany or Switzerland.
Created attachment 370359 [details] Correct Display on MacOS 10.13.3
Created attachment 370360 [details] Fails on 10.13.4 beta So this is interesting. On my MacPro with 10.13.3 the month displays correctly as shown in the previous screenshot, but on my MacBook Pro with 10.13.4 Beta it does not. Christoph, what MacOS version are you running?
It's a Macbook Pro with 10.13.3
Same issue, MacOS 10.13.4, GnuCash 3.0 and 3.1, locale ru_RU. Weekdays are also shown as "(null)"
Created attachment 371627 [details] Calendar bug for v3.1
Well, this drove me bonkers: I could only reproduce it when it was built and bundled on Mavericks and then run on High Sierra, and only then if I launched GnuCash by double-clicking on it in Finder. Even "open Gnucash.app" from the command line wouldn't reproduce. Recompiling Glib with optimization disabled also prevented it from reproducing. Here's the good news: Updating GLib to 2.56.1 seems to fix it. Please reopen if it still doesn't work in GnuCash 3.2.
Created attachment 372824 [details] Calendar bug for v3.2 Nope, still can see nulls. Version: 3.2 Build ID: 3.2+ (2018-06-24)
What if you launch it from Terminal?
Starting from console fixes this issue, thanks. Is there any way to make it work when starting in a common way?
(In reply to Yury Samsonov from comment #17) > Starting from console fixes this issue, thanks. Is there any way to make it > work when starting in a common way? Probably not without changing the localization code. It must be configuring the wrong character set when launched via LaunchServices but not when launched from a shell.
Now I can't reproduce it at all except in 3.0. Yury, are you using the Russian language and region settings in System Prefs or have you modified Gnucash.app/Contents/Resources/etc/gnucash/environment?
Same problem for me Language is French, it only occurs when month contains an letter with Accent "é" "û" OSX 10.13.6 (17G65) Gnucash Build ID: 3.2+ (2018-06-24)
*** Bug 797087 has been marked as a duplicate of this bug. ***
Created attachment 373401 [details] Bug for Build 3.7+(2019-09-07) Bug was fixed in version 3.6+, appeared again in 3.7 Well, not really fixed - calendars was in English despite the fact that the system locale was ru_RU.UTF-8. Well, better have calendar in English then with nulls :)
I notice this still has the status "needinfo". Is there specific information needed for someone to look at trying to fix it or is it just that it is low priority? The problem is still in version 4.2 on MacOS 10.14.6 Starting Gnucash from within Terminal results in the calendar being correctly displayed in Japanese but it isn't very convenient. Editing the environment file in etc, where by default the "LANG" line is commented out, allows me to display the calendar in English if I set LANG to "en_GB". If I set it to "ja_JP" the calendar isn't displayed correctly. In the case of Japanese it is not just the month but the days of the week as well which don't display.
It was need info for the question in comment 19 that Yuri sort-of answered in comment 22. As for priority, there are certainly more pressing problems. Add to that that I'm at a loss to understand why launching from Finder shows the problem while launching with `open`, which is supposed to do exactly the same thing, doesn't.
I played with this a bit just now and I may have a workaround. Quit GnuCash. Edit Gnucash.app/Contents/Resources/etc/gnucash/environment; TextEdit will do fine for this but don't use a word processor like Pages, M$Word, or LibreOffice. When you save don't let TextEdit add an extension. Find the line that with #LANG=nl_BE and change it to LANG=ja_JP.UTF-8 . Yuri, you'd use ru_RU.UTF-8. Start GnuCash and see if the calendar widget displays correctly.
Thank you. The workaround works! I hadn't thought to put ".UTF-8" on the end because I'd assumed MacOS would use UTF-8 by default for ja_JP. (it also appeared in warning I noticed when I ran the Gnucash binary directly "gnc.gui-WARNING **: 08:30:06.186: [mac_find_close_country()] Using ja_JP instead.") Just for the record, I started to edit the environment file in Gnucash.app/Contents/Resources/etc/gnucash/ only when I was trying to fix the calendar display problem. Until then it had the default content. As I mentioned, setting "LANG=ja_JP" in this file did not work but your suggestion of "LANG=ja_JP.UTF-8" does.
And with that insight I was able to easily fix the problem in GnuCash's macOS locale-setting code. Fixed for GnuCash 4.3.
Great. That's good news. Thank you.
