GnuCash
Contact   Instructions
Bug 795247 - datepicker broken in Persian
Summary: datepicker broken in Persian
Status: RESOLVED FIXED
Alias: None
Product: GnuCash
Classification: Unclassified
Component: User Interface General (show other bugs)
Version: 3.0
Hardware: Other Linux
: Normal normal
Target Milestone: future
Assignee: ui
QA Contact: ui
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-14 00:51 EDT by Bill Nottingham
Modified: 2018-06-07 23:06 EDT (History)
7 users (show)

See Also:


Attachments
screenshot of calendar (151.45 KB, image/jpeg)
2018-05-03 06:48 EDT, Bob
no flags Details

Description Bill Nottingham 2018-04-14 00:51:32 EDT
Steps to reproduce:

LANG=fa_IR.UTF-8 gnucash

The datepicker in the register is not functional.

Symptoms:
- defaults to (apparently) 2017-11-29, even when the date is today (2018-04-14)
- clicking right arrow for year does nothing
- clicking left arrow for year moves two years prior
- clicking either arrow for month(?) moves one year prior
- clicking any date moves one year prior

Works in Hebrew and Arabic (Egypt), so it's not something specific to all RTL languages.

(originally filed in Fedora at https://bugzilla.redhat.com/show_bug.cgi?id=1566741)
Comment 1 Geert Janssens 2018-04-27 07:48:13 EDT
I can't reproduce this (any more) with a build on Fedora 27 from current maint branch:
https://github.com/Gnucash/gnucash/commit/d0fca7794e58063138ad201e73a6254184b56e2e

There have been a lot of fixes in the area of date handling. Perhaps one of those has resolved it.

Can you test with a recent maint build ?
Comment 2 Bill Nottingham 2018-04-30 14:47:00 EDT
Still there in a 3.1 build for me. Is that significantly different from maint?
Comment 3 Geert Janssens 2018-04-30 15:06:30 EDT
Unfortunately no. 3.1 was released from the maint branch. I wonder if this is Fedora 28 specific as I can't reproduce it on my Fedora 27 system. I'll recheck when I upgrade to F28 in a couple of weeks.
Comment 4 John Ralls 2018-04-30 15:11:45 EDT
The gnucash-date-picker just wraps a GtkCalendar in a box so that it can be a cell editor. Maybe the Gtk version makes a difference--as in maybe it's a Gtk bug?
Comment 5 Bill Nottingham 2018-04-30 15:13:45 EDT
FWIW, I'm actually testing on a local F27 build, as I haven't upgraded yet.

The calendar widget works fine in fa_IR.UTF-8 in gtk-demo at least; I haven't tried a more complicated example.
Comment 6 Bob 2018-05-01 08:05:52 EDT
I have tried this on my Gentoo VM and can not reproduce your symptoms. I am using gtk+ 3.22.29. Have you tried any of the other calendars in Gnucash, there is one when you right mouse a transaction and try to schedule and then there are a couple when you open the report options for the sample report.
Comment 7 Hedayat Vatankhah 2018-05-02 16:47:15 EDT
I've tried the schedule page, or the sample report properties, and it works fine there.
Comment 8 Bob 2018-05-03 06:47:43 EDT
Well I do not know what is going on, I still can not reproduce when starting with LANG=fa_IR.UTF-8 gnucash

When the calendar is popped, do the keys -+ change the day, shift-+ change the week and cntrl-+ change the year ?

Is the default day correct, the same as the other calendars ?

I have added a screenshot when started with above, are there any differences ?

I am running out of ideas, as I can reproduce it is difficult for me to track down.
Comment 9 Bob 2018-05-03 06:48:25 EDT
Created attachment 371635 [details]
screenshot of calendar
Comment 10 Bob 2018-05-03 15:26:53 EDT
Last line should of read...
I am running out of ideas, as I can not reproduce, it is difficult for me to track down.
Comment 11 Hedayat Vatankhah 2018-05-03 16:28:54 EDT
Setting LANG is not enough. Either log in with full fa_IR.UTF-8 locale, or try this which should work (I've not tested):

export LC_ALL=fa_IR.UTF-8
gnucash

(If didn't work, you might try settings LANG in addition to LC_ALL!)
Comment 12 Bob 2018-05-05 06:49:46 EDT
Used your command and running locale gives me...
LANG=en_GB.UTF-8
LC_CTYPE="fa_IR.UTF-8"
LC_NUMERIC="fa_IR.UTF-8"
LC_TIME="fa_IR.UTF-8"
LC_COLLATE="fa_IR.UTF-8"
LC_MONETARY="fa_IR.UTF-8"
LC_MESSAGES="fa_IR.UTF-8"
LC_PAPER="fa_IR.UTF-8"
LC_NAME="fa_IR.UTF-8"
LC_ADDRESS="fa_IR.UTF-8"
LC_TELEPHONE="fa_IR.UTF-8"
LC_MEASUREMENT="fa_IR.UTF-8"
LC_IDENTIFICATION="fa_IR.UTF-8"
LC_ALL=fa_IR.UTF-8

If I start Gnucash with LANG=fa_IR.UTF-8 gnucash I still can not reproduce your symptoms so I am stuck.

It may help others if you specified your gtk+ version and are you using Wayland ?
Comment 13 Hedayat Vatankhah 2018-05-05 15:01:48 EDT
No, I'm using Xorg.
Gtk3: 3.22.30
Comment 14 Bill Nottingham 2018-05-16 21:26:48 EDT
I'm using Wayland, but same GTK version.

Bob - what is your date format set to in preferences? If it's set to 'locale' for me it breaks; if I set it to something else, it works properly.
Comment 15 Bill Nottingham 2018-05-17 00:04:47 EDT
Czech is also very broken, for what it's worth.
Comment 16 Bill Nottingham 2018-05-17 01:27:37 EDT
https://github.com/Gnucash/gnucash/pull/351
Comment 17 Bob 2018-05-17 04:44:59 EDT
Bill, my preference was UK. If I change that to local and use the commands above I see the failure, it did not occur to me to change that setting.
Comment 18 Bill Nottingham 2018-05-22 23:35:16 EDT
For people who are really bored and/or like spelunking:
 
- 2007: the initial place GnuCash hit this was in 2.2 with Czech ('-'), Polish ('b'), Tamil, Nepalese, etc.
- 2007: it was kicked to glibc for the Polish case (https://sourceware.org/bugzilla/show_bug.cgi?id=4772)
- 2007: the Polish locale data was changed via vote (!) because of this and related items (https://sourceware.org/bugzilla/show_bug.cgi?id=4098)
- 2013: strptime in glibc actually got fixed for the '-' case (https://sourceware.org/bugzilla/show_bug.cgi?id=4772#c10)
- 2014: Geert in 2.4 prep added the original patch to remove '-' with Czech as the motivation (https://bugzilla.gnome.org/show_bug.cgi?id=497831) 

... and now we are here.

(note: even with my proposed patches, Tamil and Nepalese are broken for manually editing dates, but they were beforehand.)
Comment 19 John Ralls 2018-06-07 16:31:44 EDT
Bill, PR351 is merged (thanks). Can this be closed?
Comment 20 Bill Nottingham 2018-06-07 22:07:57 EDT
OK with me; up to you and your process how you want to close it.

Note You need to log in before you can comment on or make changes to this bug.